I'm looking to make a somewhat ambitious Arduino project with a partner that uses wireless communication via NRF24L01s between Arduinos and I need to make a digital prototype to code/test while they work on the hardware side of things (making the circuit, making 3D printed enclosures, etc.).
After looking around a bit, I've seen 3 popular platforms that aim to solve this very problem:
Wokwi, a website/VSCode extension that claims to be the "most advanced ESP32 Simulator in the World" (with support for most popular arduino devices),
Fritzing, the de-facto wire modeling software that recently introduced arduino simulation a couple years back, and
Flowcode, a for-profit circuit modeling/coding software that apparently can import 3D models?
Out of the three, is there one that you recommend/prefer? Or is there different software out there that's better than the ones I found? Or is it just weird to be doing this in the first place? Love to hear your opinion
I haven't seen that it offers a simulated radio component of any kind.
It doesn't allow use of two Arduino boards on one simulation.
So while you might be able to develop and perfect some parts of the software, the part that will undoubtedly be the hardest to get working is the code that will deal with the radios.
A simulation that allowed two Arduino boards yet did not have a radio component would not be useless; if the functionality of the radio is designed properly, the communications part could be faked by using an alternate means.
At high level you are transmitting and receiving packets, you could send and receive the same packets using serial comms or SPI or even I2C, three I have listed in the order of how hard they might be to use, none is especially difficult.
TBH I'm not sure you get much of a win using any simulation.
In my opinion your best bet is to buy two Arduinos that use the same processor as your final design, two nRF modules and an additional power supply for the nRF modules.
Hook it up and start testing. The code that you write can later be used to test the communication of the final product(s).
Repeat (as much as possible) for other components.
Not a fan of simulators myself. They do not do things very well. For example I2C lines without pull up resistors seem to work with simulators where as in practice this often causes trouble. Also voltage miss matches do not go BANG like they would in real life. Finally they tend to have a very limited sub set of Arduino processor types.
Simulation is a great tool, but it doesn’t account for issues caused by bad hardware, poor assembly, faulty parts, or unstable power sources. For example, NRF devices are notorious for problems when the power source is unstable.
The best tools for diagnosing and troubleshooting are a multimeter, logic analyzer, oscilloscope, and any equipment necessary to test the calibration of the modules you’re using. Additionally, simulations often fail to incorporate factors like EMI (Electromagnetic Interference), electrical noise, and other real-world challenges.
Another key concern is the computational power required to run a detailed and accurate simulation in a reasonable amount of time. While simulation is a helpful starting point, hands-on testing is essential to address these practical issues effectively.
This is an extremely challenging project. What type of team have you assembled to execute this design? Do you have the necessary expertise across key areas like hardware design, software development, project management, and testing? A multidisciplinary team with clear roles and responsibilities will greatly improve your chances of success.
God dangit-- I really didn't want to buy/wait for the stuff to come
Using radios to receive packets is that much harder than wired? This will be my first time manually implementing wireless communication into a project, so I'm curious: where would the extra complexity come from? I'd assume that it works pretty similarly to wired, save for some extra setup? I probably will be using a library or something to use the NRF24L01s, so thankfully I won't have to figure out how to encrypt/decrypt things for wifi transfer
That's probably what I'll do: Test initially with 2 to build a basic framework to build off of, then introduce the other 5 Arduinos (and maybe smartphone?) after the fact and implement the rest of the stuff I wanna add
Yeah-- I get the realism part. I've heard a lot of people have gripes about simulators not simulating well, but my mentality's always been that to the very least they're better than just making electrical diagrams. There's no way a simulator can be perfect, but they can help visualize all the stuff you'll potentially need to make a project and how they could fit together. Then when you make the first prototype, you can fix the inevitable wiring errors when they come up with a multimeter or what-have-you
The other party is designing and building the hardware. They are hopefully prototyping on breadboard or veroboard. Not doing so will result in numerous iterations of hardware design and each time a new production run for a PCB (if applicable)..
For the other party to be able to test properly if their design is correct, they will need microcontroller software (a sketch in the Arduino world) as there are microcontrollers involved so they can at least test the individual parts of the design.
Yeah-- I've heard that the NRF24L01 needs a 10-100 uF capacitor to operate properly from some warnings on its data sheet (as well as the fact that I would blow the thing up if I used 5v power on it). I've only just started thinking about the hypotheticals of the project the day before and only just finished a potential materials list with my partner, so now the next step is to build some sort of mockup to verify everything on the material list is actually what we're going to need.
I'm not much of a hardware guy, so I figured the easiest and fastest way to go about making this would be to work with my partner to model it in a simulator (it's hard for me to visualize what's happening in electrical diagrams), then I could do some coding while we waited for the parts to come and for the prototype to be built.
I'm aware that there are probably going to be some problems that the simulator won't foresee, but such problems can usually be fixed/amended pretty easily by making slight adjustments to the simulator mockup or by including safety in the code used to properly simulate the mockup
An all-star team, consisting of me, a mediocre coder who has never worked with wireless protocols and absolutely sucks using their hands, and my partner, a person that laps me hundred times over in technical knowledge but knows less than me in the software department.
Thankfully, the project itself won't be too intensive on the coding side-- just need to code for 7 Arduinos (and potentially 1 smartphone) to be on a 6-data-pipe NRF24L01 as well as handling an LCD and a 4-digit 7-segment display (Yes, they have to be separate) through 2 daisy-chained shift registers because my poor, overworked Arduino doesn't have the 30+ pins to process all the components it will inevitably have to deal with. Yeah, we totally got this
Nope, at least not to the scale of what I'm doing now. In fact, I'm drafting a new forum post to make sure the double-shift register maneuver I talked about before is actually possible to begin with. Right now it's just a theory, but since the shift registers we're planning to get have a latch pin, I'm pretty sure it's doable
Yep-- the original plan was to go from Mockup to Breadboard to Sodered/Enclosure-Fitted Prototype to Polished enclosure/PCB. Of course, the initial mockup and breadboard stages have sub-steps to them since we have to test each part of the finished system before moving on to the next draft but trust me when I say that we do NOT have the cash to be throwing at dud PCBs
Exactly! The original idea was for me to make an initial draft of the software in between the mockup and breadboard phase so the first draft of the code could be ready for real-life debugging when the parts come and everything gets assembled. But there doesn't seem to be a digital mockup out there that can use more than 1 Arduino at once so I'm out of luck
The hardware party should provide you with the design. Till you have that you can't do much.
Once you have the design, you can write the code for the individual pieces; in case of the nRF both receiver and transmitter. Make sure that you can compile them without errors and understand possible warnings and the possible side effects of those warnings that come from the libraries and the board packages.
The hardware party needs to set up the IDE on their computer system and install exactly the same board packages and libraries as you have; different versions of either might result in problems.
My preference for the IDE for this project would be a portable install of IDE 1.8.19 (IDE 2.x does not support a portable install). It's self contained.
I would use teamviewer so I can remotely access their system / look over their shoulder and modify / upload the code using their PC if needed. The same options might be available in zoom and teams.
I would order asap a couple arduino and associated radio component and hook them up. There are thousands examples over the forum and on the web to show how to do that. Those components don’t cost much and (depending on where you live) could probably be in your hands in less than a week.
Use that week to get acquainted with the arduino environment if you are not familiar yet and read the doc for the RF24 library and some tutorials plus of course have a look at the datasheet of the radio.
You could use the simulator to test some algorithms if you feel that’s needed.
I mostly use the simulator when I don’t want to take the time to wire up a few of their existing parts or have to deal with power etc knowing this can be looked at later. I also use the simulator when I want to share an example code / demo since it’s super easy to share a link.
Also can I ask why you picked that type of radio? Choosing this comes usually from a study of requirements and constraints. It’s not the only cheap choice out there.
Side note:
If you use wokwi for something ambitious or semi pro / pro I would recommend you fork a few €$£¥ out to support them.
Wokwi is good but has its known limitations especially in the analog area with resistors as potential dividers etc. etc. and that only one MCU board can be used in a project. Proteus projects turn up here from time to time and it appears to be much more complete but is too expensive for normal hobby use, however, bulk education licences seem to be cheap enough for some schools.
Real hardware, as already suggested, is always a good solution but I can see why schools like the simulator because it means that students can easily submit their projects for assessment.
Don't. Stay here, you have our attention, we kinda know you now. There's already information you will only be pestered about again in a new thread.
I also wonder about the choice of the radio. But they can be made to work. Poking around will show up that many ppl have trouble; it is highly recommended that software you did not write and schematics you did not draw be used to thoroughly test a simple "hello world!" set of sketches found in a competent tutorial.
There is at least one simulator that will let you use two boards. I don't remember which and cannot speak to its quality.
The disadvantages of the wokwi can be seen as advantages, in the sense that it can relieve a noob of all worrying that her circuit is bad, the components damaged or faulty out of the box and so forth. No dodgy ports or cables. No possibility of destroying spendy gear.
As @J-M-L says and others at least hint at, it shines for emulation of the software. The jelly bean components work well, usually the more sophisticated ones work, but it is often easier to use a slide fader as a proxy for a sensor. LEDs and pushbuttons (that simulate bounce!) can substitute for all kindsa things and…
… properly structured, a huge part of the sketch can be perfected in the absence of real world problems.
The wokwi runs the code through the same too chain as the IDE, and then executes the code on an emulation of the microprocessor chip. It does not get better than that. On a desktop machine, sketches usually run at real time speeds. There is a "real time" clock and percentage speed being posted at all times, so you can see if.
+1 for supporting them at whatever level you can, I understand you mayn't be able to. It has been a world changer for me, if only as a great way to share simple sketches and easier than lashing up simple circuits IRL. I usually get the bulk of the code done for most things long before I commit to a hardware design or buy parts.
A development model known as IPO can help separate logic from reality. Read about it here: The IPO Model. Or ask chatGPT to tell you all about it, or indeed search these fora. It does get mentioned.
Most of the time, we can meet up IRL to collaborate on the project, but in past projects when we needed to remotely meet to build project stuff, we would do something different. Instead of using Teamviewer, we would set the project's sketch location to be inside a GitHub repo to pull/push code updates to each other, then screenshare in Zoom so I could see the serial monitor. Teamviewer would probably be better than screensharing the serial monitor though, so I might steal that idea
I'm sure I could make up a ton of valid-sounding reasons why we chose to use a NRF24L01, but if I have to be honest the real reason why we chose it was because we found it for less than a buck on AliExpress lol. The only thing is that it won't arrive until early December, so I wanted to be at least somewhat productive while we waited for it to come. We haven't bought anything just yet though, so I can still change it if there's something out there that just blows this out of the water. Let me know other chip ideas when you can!
Maybe, but I've yet to properly use it outside of a bit of messing around with it before making this post, and I can't really use it for this project either because it can't have 2 boards out at once. I like the idea of being able to share what my project looks like with other people though-- this probably won't be the last time I ask for help/opinions on this forum. If I can figure out how to get multiple boards on there (even if I can't code them or anything) I'll go with Wokwi going forward.
First time I'm reading this topic, but I second the previous opinions on Wokwi being the best and not being enough for your case. The previous answers came from high qualified people that are here almost in a daily basis.
From the hardware side, maybe the RF-Nano is a board that can be of your interest. It's a Nano platform that already has a NRF24L01 "bult-in". I don't have one myself but it caught my attention a few times before.
Anyway, considering the statement below:
would you mind telling us the distance between the boards and how much information they'll be sharing? This might explain why are you choosing RF instead of Bluetooth or BLE or WiFi.
NRFs beeing well known to require a real good power-supply.
You can really believe in the experience of the users here:
You will have MORE trouble getting NRF24L01s to work
than
two ESP32-boards that have everything on board
microcontroller
enough RAM
enough flash
Wireless connectivity through WiFi
There is NOTHING to encrypt or decrypt when using WiFi on a ESP32-board
encrypting / decrypting is all done "under the hood"
The ESP32-Boards can send and receive data over UDP, TCP and a special protocol called ESP-NOW.
You have to take care of using several function-calls to setup the ESP-NOW-communication
which is just writing code that can start from simply copy & paste an existing demo-project.
One source for ESP32 / ESP-NOW is random nerd tutorials
