As long as you are using the LoRaWAN protocol (not just LoRa modulation), encryption is not optional. It's built into the link layer of LoRaWAN, and a device cannot join a network without a unique key that's shared out of band.
Also, the range is entirely the point of using LoRaWAN for some of us. All other IoT protocols have an abysmally short range, making them impractical for anything other than single building applications. Maybe most don't need a mile of range, but the fact that it can reach across a couple of acres enables a lot of applications.
Interesting concept for a project...
From what I have seen in the industry, it seems like this is something every organization ends up developing at least one custom tool for. EDA vendors even generally sell their own solution to this problem, but we always end up back at custom tools. It would be interesting to see if community collaboration could find a better general solution.
That said, it seems like Smelt is far too early in development to be practically used at this point. Some basic table stakes that I didn't see:
- Test weighting. Having a way to specify a relative repeat counts per test is essential when using constrained random tests like we do in the ASIC world.
- Some form of tagging to identify a test as belonging to multiple different groups. When combined with a way to intersect and join groups when specifying the tests to run.
- Control over the random seed for an entire test run. I was glad to see some support for test seeds. However when invoking smelt to run multiple tests, it would be nice to be able to reproducibly seed the generation of each individual test seed. Maybe this is outside the scope of this project?
Great things to see:
- Procedural test generation is a key feature.
- Extendable command invocation
- SLURM support is in the roadmap, also an important feature for groups that use SLURM.
I have one of these scopes, with exactly this issue after a long period in storage. When I was looking into it a few years ago the failure mode was known but I couldn't find a recovery procedure. I'll need to give this a try when I get a few hours. I have been putting off getting a new scope in hopes that I could repair this issue.
I don't understand why fuzzing hardware is being presented as a new thing here...
In silicon validation, constrained random testing has been the standard methodology for at least 10 years. With the complexity of modern CPUs, it's effectively impossible to validate the hardware _without_ using some kind of randomized testing, which looks a whole lot like fuzzing to me.
What is new here? Or is this a case of someone outside the industry rediscovering known techniques.
Started a couple years ago, but I don't have as much time to write as I'd like. The majority of topics relate to ASIC design and verification, since that is my day job, but with some other side projects mixed in.
The picture frame secretly ran Android under the hood. Which meant I could replace the app which showed pictures pulled from the manufacturers server, with one which pulls photos from the NASA website. Fortunately they left ADB enabled with root permissions, so it was trivial to replace their startup app with my own.
All the source code is public here: https://gitlab.com/prbs23/mars-photo-stream
The owner, the Frank Morton who was mentioned in article, is the original breeder of both Gildenstern and Dazzling Blue (and they probably grew the seed being sold by Fedco). All the varieties he bread (of which there are many) are released as OSSI varieties, plus they sell other OSSI varieties as well.
Most architectures do not provide an interrupt that is generated by an integer overflow. Since this would be a significant architectural change in the hardware, it can't be simply added in.
Additionally, if you are running inside an operating system, handling an interrupt usually incurs a trip through the kernel, which would add extra overhead every time an overflow did happen. Since there's a lot of software which depends on integers overflowing, this overhead on each overflow could significantly impact legacy software.
LoRaWAN is definitely an interesting mix of open source implementations and open specifications, and proprietary poorly documented hardware. Unfortunately I haven't had time lately to actually use my network for anything real.
As others have said it's not the concept of DWDM that's new here. That has been around for a while. What is interesting here is that they have managed to integrate a DWDM transceiver onto a single silicon-photonic chip.
As someone who has worked in similar silicon-photonic research, the challenge is to create the required filters, modulators, and demodulators that are stable enough over environmental conditions and manufacturing process variation for commercial production. Most silicon photonic structures are quite sensitive to temperature in particular.
> No. I won’t do that. It inhibits natural communication.
Quite the opposite, it inhibits effective communication.
Giving someone a one sentence summary of why you need to talk enables them to be prepared for the discussion you want to have. This lets you get to the point faster, and reduces miscommunication.
I don't get why this is such a burden for you to be clear in your communication.
From what I have seen of both the open source and commercial EDA software, I think it would take a well funded team somewhere around 4 years of development to catch up with the current state of the art. If we're talking about EDA emulation hardware, probably more like 6 years, since these usually have custom Basics designed for them.
Maybe you could cut a year off of those and still have something that is good enough but not state of the art.
You seem to have already made a judgement about IME and associated management processors by calling them backdoors. Intel doesn't put IME into their processors to be a back door, but to, as the name suggests, manage the processor. The fact that a malicious actor may be able to exploit the IME as a backdoor doesn't change it's actual purpose.
The fact is that modern processors/computers are so complex that it's simply not practical to build one without some kind of initialization and management processor or other programmable device. Intel, AMD, ARM, it doesn't matter. Any processor of this size will have at least one if not more management processors.
Maybe these companies could do better and release the source code of what runs on these management engines, and I would argue they should. But unless we want to go back 10 years in processor complexity and performance, the "Backdoors" as you call them aren't going anywhere.
I totally agree that having visual diagrams of a code base can be super helpful, especially when getting familiar with the code, or onboarding a new engineer. However I don't think we see automated tools because generating a useful diagram from source code is not a solved problem.
Fundamentally I think that the useful kind of software or system diagrams are always abstractions of the actual code. Figuring out the correct abstraction for the intended purpose requires either experience or a lot of trial and error. It may be possible for very specific applications, but I kind of doubt there is an algorithm to generate the content for a useful system diagram from the raw code.
Then there is the problem of rendering and layout out the diagram automatically. We have Graphviz and Mermaid, and probably others I haven't heard of, and while these do an okay job, I've never found their layout algorithms to be particularly great.
Overall, I don't think anything is going to be as useful as a manually drawn diagram, made with a specific intent in mind.
It feels like there is a cultural difference here.
If someone tells me something in a one on one or small group conversation, my default assumption is that I should not share that with anyone else. The idea that I would have to tell someone to not share details of a private conversation is crazy to me. Unless stated otherwise, respect people's privacy.
Obviously there are people that gossip, which is kind of the same thing, but also is very much frowned upon.
I've been following the IceStorm project for a while and it's some really impressive work. Now if only we could get a decent open source SystemVerilog simulator to go along with it. As someone who works in the ASIC design world, the thing that makes my side projects die out is usually the state of the open source simulation tools. I have tried to use both Verilator and Icarus, and both have so many limitations and quirks beyond what I'm used to with the commercial tools gave up on them.
I keep telling myself I need to dig into their source code and start fixing problems, but going from user to developer on these kinds of tools is a big jump.
Also, the range is entirely the point of using LoRaWAN for some of us. All other IoT protocols have an abysmally short range, making them impractical for anything other than single building applications. Maybe most don't need a mile of range, but the fact that it can reach across a couple of acres enables a lot of applications.