I am almost done getting all individual parts working and now I need to put it all together. However, due to all the sensors I am not sure 1 arduino is enough to process it all.
I will be fitting my RCcar with these sensors/breakouts:
7 Hall Sensors for RPM per driveshaft
GPS
Gyro/Compass
2/3 Temp sensors
a bunch of dimmable leds
logging of throttle and steering position
2 x 433Mhz or 1 Wi-Fi (tbd)
Current and Voltage Sensors
MicroSD slot for data logging
Later on possibility to intervene with car control.So, all controls through arduino (tricky!!)
The arduino will log every sensor on micro SD so I can analyze the data on PC.
The car will be sending live info to another arduino (max rpm/speed etc etc)
I will also have another arduino that will be able to change the settings of the car remotely (turning on/of GPS/Datalogging and other sensors) and I will be able to see batterystatus on this arduino.
The Car-Arduino will be fed with a small 3S lipo and 2 DC-DC converters. 1 for Arduino, 1 for sensors/leds. The arduino will only control things not power them.
I know that smart programming is 80% of the deal and it's winter. I will be doing a lot of testing and asking questions/reading.
Is 1 arduino/atmega328 powerfull enough to process this information AND send some info to another arduino AND log it onto an SD?
I probably will use bear ATMEGA's instead of UNO or Nano. I already have 1 working on a breadboard thanks to this forum and YouTube.
Just to be clear, my question is only about sizing. The howto I want to find out myself Or if needed I will open another topic.
Sareno:
I am almost done getting all individual parts working and now I need to put it all together. However, due to all the sensors I am not sure 1 arduino is enough to process it all.
Did you do a pin count? A Mega comes with some 70 I/O pins (of which 16 with analog input ability). Likely it will all fit.
But there's a lot of information missing:
7 Hall Sensors for RPM per driveshaft
What's the maximum rpm they have to handle?
a bunch of dimmable leds
Simple DC LEDs? Then you can use PWM pins. 14 of those on a Mega.
logging of throttle and steering position
How much data to be written to the SD card?
2 x 433Mhz or 1 Wi-Fi (tbd)
Why 2x 433MHz?
How much data to be transferred?
Programming is key. Sticking to a single processor is usually the easiest, but you can consider using a separate Arduino for the logging, receiving the logging data over Serial or I2C from the main controller, then writing it to SD card as that's a relatively slow process.
The reading of the rpms is another that you may consider offloading, basically turning the hall effect sensors into a set of rpm sensors.
I am not worried about the pin count. I will use breakouts for that. 74HC595 or the... (forgot the type). Anyway, that I will solve when I get there.
10K RPM max for 3 sensor, other 4 around 3-5K RPM
Simple DC leds but too much current per pin for the Arduino. Also, I want to disconnect power from control. I will use multiplexers with mosfet if I need to dimm them and the 595 for on/off only.
How much data, well, that part I just dont know yet. I have to determine the interval on logging to get a decent graph.
433Mhz in 1 direction only I have read. So 1 receiver and 1 transmitter need for bidirectional communication. I found a tranceiver but with bad reviews.
433Mhz seems to be more reliable than WiFi with a longer range but correct me if I am wrong.
What it needs to do is:
Send info from car to remote arduino:
Battery Status (Realtime)
Max RPM Engine (on request)
Max Temp of sensors (on request)
Max Speed (on request)
Acc times (0-30mph or something) (on request)
Session time (on request)
Confirmation that information from Remote arduino has been received and processed.
Receive from remote arduino to car:
Change in setup (Gear ratios, tyre size etc)
Change in setup fan speed, temp threshold
Toggle logging/GPS/GYRO etc on and off
This might look like a whole bunch of nothing but the arduino in the car will be fitted in a waterproof enclosure that I do not what to open if not strictly needed. That is the only reason why I think about using WiFi to download the SD card. How ever I could put in Wifi as well but only enable it in a sort of "download-mode". When the car is at home near my home network.
The on/off toggle of all sensor might come in handy when power is low.
Sareno:
433Mhz in 1 direction only I have read. So 1 receiver and 1 transmitter need for bidirectional communication. I found a tranceiver but with bad reviews.
433Mhz seems to be more reliable than WiFi with a longer range but correct me if I am wrong.
Depends on which radio you use. There are numerous very different radios that use that frequency. Some have a range that's no match for WiFi (such as LoRa), others (you'll be able to find them on eBay and the like for very cheap) barely reach other side of the room. HC12 and RFM69 are half duplex in transmitting, but they're transcievers and will handle send/receive for you. Both reach further than WiFi or Bluetooth, which in turn have much higher transfer rates (by a 1-2 orders of magnitude).
Sareno:
I will be fitting my RCcar with these sensors/breakouts:
7 Hall Sensors for RPM per driveshaft
Why would it have 7 driveshafts? One sensor should be sufficient for detecting RPM.
GPS
How big is the car, will it be working outdoors and what distances will it be moving?
GPS needs to be outside, and clear of tall buildings and it is not useful for measuring small distances.
If you are prepared to build your own hand controller then my recommendation would be to use a pair of nRF24L01+ transceivers. This Simple nRF24L01+ Tutorial may give you some ideas.
Robin2:
Why would it have 7 driveshafts? One sensor should be sufficient for detecting RPM.
How big is the car, will it be working outdoors and what distances will it be moving?
GPS needs to be outside, and clear of tall buildings and it is not useful for measuring small distances.
If you are prepared to build your own hand controller then my recommendation would be to use a pair of nRF24L01+ transceivers. This Simple nRF24L01+ Tutorial may give you some ideas.
...R
The car has 7 points of measuring for telematry. All shafts will be rotating at different speeds and I want to see that so I can change te setup of the car.
The car is a 1/8 truggy, standard RC brushless very fast unit. Outdoors ofcourse.
I will remain using my standard 2.4GHZ remote for safety. The arduino is purely meant for measuring purposes at this point. It can only control the lights, max braking force and fan speeds.
When I become better at this and learn to code better etc etc I might upgrade to GPS return-to-home or something but that is a long way from now.
I am putting myself to this challenge to learn. Blinking a led already starts of with the wrong use of delay
At home I already have environment system setup with arduino, this is the next challenge
wvmarle:
Depends on which radio you use. There are numerous very different radios that use that frequency. Some have a range that's no match for WiFi (such as LoRa), others (you'll be able to find them on eBay and the like for very cheap) barely reach other side of the room. HC12 and RFM69 are half duplex in transmitting, but they're transcievers and will handle send/receive for you. Both reach further than WiFi or Bluetooth, which in turn have much higher transfer rates (by a 1-2 orders of magnitude).
I am googling for hours but either with bad reviews or not to be shipped to NL or a lead time of 6 weeks. I want to establish a bidirectional connection between 2 arduino's over a distance of 200Meter stable. The only data that has to be real time is battery connection and RPM. Other info on request only (no larger files or something, just an output of other values but that is allowed to take a while).
I already ruled out WiFi because most of these breakouts are bad quality and the range.... mwoah. Let alone the interference. Can somebody point me to a HC12 or RFM69 that is good enough and available in NL? (if this is indeed the right choice?)
2: I cannot find the right temp sensor I need. Most are either breakout boards or led-like thingies. I need a very flat interface-cable-like sensor. I remember having those in my pc to past on the heatsink of the cpu or on the hdd but I cannot find them anywhere. I have to squeeze it between batteries and between a brushless motor and its heatsink.
Major suppliers such as Digikey ship everywhere and stock RFM69 modules.
Do a Google image search for "thin temperature sensor". You'll see thermocouples, thermistors and RTD sensors that are about 1 mm thick. If that is too thick then you'll need to make your own using fine thermocouple wire.
Sareno:
I will remain using my standard 2.4GHZ remote for safety. The arduino is purely meant for measuring purposes at this point. It can only control the lights, max braking force and fan speeds.
Using the standard remote for control makes sense.
Be aware, however that the standard RC is probably using an nRF24L01+ for its wireless, or the Cypress equivalent. With a high-power nRF24 (with external antenna) at your base station I would expect you to have no trouble with the 300m range. I have had a pair of low-power nRF24s working at 110m outdoors with clear line of sight.
Merging makes sense but I also makes it a bit confusing:
Anyway I needed to read 7 hall sensors. This came out of another discussion. What do you think?
david_2018:
Hall effect sensors measuring shaft rotation is not a good application for a multiplexer, because the sensors generally are going to be outputting a very short pulse, and the arduino needs to respond to that while it is still active. You would probably want to connect the sensors directly to the arduino inputs, and then have an interrupt service routine (ISR) that responds whenever the input levels on any of those pins changes (a pin-change interrupt). Might be possible to get away with the multiplexing if the shafts were rotating very slowly, or you only wanted to measure one shaft at a time.
That might be a challenge, the UNO only has 2 interrupt pins, I need 7.
Maybe I should add a Arduino Micro that has 20 digital pins for reading the hall's and writing SD. Would that be powerfull enough? The only one with enough interrupts is the DUE but that is EOS. Maybe I can also control the lights with the micro so I have the first arduino for GPS/Gyro etc.
Then still, the Uno will interrupted all of the time, slowing the rest down.
BUT, If I take another small type of Arduino with enough digital pins, I can do the same trick without overloading the first Arduino, right?
It's really too bad that the Atmega328 has so little pins and that I have so little room. Otherwise a mega would be a good idea. Unfortunately the chip from either the mega and the micro cannot be used as a separate controller like the atmega.
Well the ATmega2560 chip isn't that much bigger than the ATmega328p... and there are pro versions of the Mega out there as well, that are maybe the size of an Uno.
You can't get around "getting interrupted all the time". You have 7 signals, that's a lot of interrupts no matter what. You can make things a little more manageable by putting them all on a single PORT so you have only one ISR to deal with all hall effect sensors, and of course you only enable interrupts on the pins of interest.
You end up with a maximum of 50,000 pulses per minute, that's 833 a second. Of course all are counted double (falling and rising) so some 1666 ISR calls a second. That's going to require you to write efficient code - so no digitalRead() calls in the ISR but direct register calls, for starters. Then it's perfectly doable. A Mega is not going to help you here as it's just as fast. As I said before you may consider offloading this to a separate Arduino, doing just the rpm measurements.
2560 is not much bigger but more difficult to place on a pcb (for me).
Putting on a single port... thats over my head I guess. Maybe you can send me a link with more info?
Direct register calls, same story. Sounds difficult.
Offloading is (like my last post) the way to go for me I quess. Will that arduino have enough time "left" to control lights and sending small bits and pieces to my base?
You mentioned port expanders.
While they’re fine for relatively ‘low rate’ signalling, you’re going to waste a lot of time serialising the various I/O in this application unless you use a much faster processor.
I’d suggest sticking with fast parallel where you can.
If you need a second processor, as noted, hive off the slower non-real-time tasks (logging, lights, even comms) to the second processor, and keep the performance / responsiveness on the main cpu that needs to be available.
This is a cool project, but will teach you a few things during the five or six revisions you’re facing!
Or if needed I will open another topic.