49 replies to this topic

[Kingbob]

In this case unfortunately no. Its the size of the added libraries that push it over. The library for the OLED is already large so that takes up a load of room. I have had a couple of ideas to try and shrink it but havent had time to try them yet.

[DjOnslaught]

In this case unfortunately no. Its the size of the added libraries that push it over. The library for the OLED is already large so that takes up a load of room. I have had a couple of ideas to try and shrink it but havent had time to try them yet.

Can you "Daisy chain" arduino's together then in order to make it work?

I suggested the SD card for the main code, in hope it would free up space for the libraries to go on the main board ram. I wonder if a mini would have enough ram for it since a nano doesnt.

[Kingbob]

It's flash not ram that's the issue, they pretty much all have 32k.
But I had some success last night, had to change the oled driver library for a smaller one, which meant changing fonts, but got it down more than enough.

I did find a small bug with the rpm counter to do with current draw, but it does all work now.

[DjOnslaught]

Nice man, you gonna do a schematic and some pictures?

[Kingbob]

Yeah will do pics tonight, and diagrams once i get the rpm issue sorted.

 

I think its a voltage/current supply issue. When the motors are powered, the rpm counter is unreliable, but let the power button go, and it counts properly.

 

Unless its plugged in to USB, in which case it works fine with the motors powered. My guess is that when the motors are running, either the voltage drops too low for the sensor to read properly, or they draw too much current and the sensor cant pull enough from the arduino. But with USB plugged in it can draw from that. 

 

Might be as simple as switching the sensor to get power from the battery instead of the arduino.

[DjOnslaught]

Maybe run the sensor off a separate battery for testing purpose. You might need a debounce code

Edited by DjOnslaught, 08 February 2016 - 09:35 PM.

[Kingbob]

Nah its not a debounce issue, it reads fine if the motors arent being driven.

 

Ie: if i press the motor button the reading is wrong, but if i release the button, it reads correct while they're still spinning. Its only wrong while they're under load.

Unless its plugged into usb.

[DjOnslaught]

I thought debounce was needed under load.

[Kingbob]

Debouncing is mostly for switches, gives you a small delay so that it only gives you one reading instead of potentially multiple.

The problem i have is that its almost not reading at all when the motors are going.

[DjOnslaught]

Could you possibllyrics have to much resistance then?

[Kingbob]

If it was resistance it wouldnt change when the usb port is plugged in.

[DjOnslaught]

That's true. Prolly a current draw issue then since you said it works fine when you don't have the blaster revved up.

[DjOnslaught]

How's this little project coming along man?   I got the stampede operating (aka got a motor, just waiting on the spring switches to get here next week and it will be fully functional.

 

I'm trying to figure out where i want to put the OLED on the stampede shell and if i want to do a select fire switch and on/off switch or just one or the other, beyond that will be a matter of plotting the counter mechanism (since its full auto) and what kinda of power supply I want to use to drive it (and how big)

[Kingbob]

How's this little project coming along man?  

 

Havent touched the Stryfe since the weekend, will hopefully be able to re-wire the power for the rpm sensor tomorrow and will be done.

[Kingbob]

Success!

 

So I re-jigged the wiring, its now using the 4xAA's for just the arduino side of things. The motors are now powered by a 7.4V 4000mAh LiPo stuffed in the butt of the gun.

The displayed voltage is for the LiPo, and the RPM counter now works heaps better, though it has a bit of trouble keeping up at full RPM!

 

So all my issues solved, and a nice little performance boost as well

 

Pics and a video soon.

[Kingbob]

Spoke too soon. Whilst i did solve my power issues, i've found another.

The rpm counter is using a standard IR LED/receiver pair mounted on each side of a flywheel. Theres a hole in the flywheel allowing the IT receiver to get a signal once per revolution. All pretty standard.

 

The code im using counts the number of signals received every 250ms, and multiplies it out to give an rpm count. The reason i do it every 250ms is so the display updates at that rate. Whilst its more accurate if I count for say 1 second, it also means the display would only update every second which is very slow.

 

The way the arduino counts the signals is by using one of its interrupt pins, so whenever the IR receiver gets a signal, it interrupts the arduino and forces it to count, before going back to what it was doing. Thats what the interrupt pins are designed for, and work well. 

BUT, what ive found in practice, is that when the motors are at max RPM, (somewhere around 25,000rpm) the counting fails.

 

It could be the IR sensor not being able to output fast enough, its rated to 37,000hz, which seems coincidentally close to the 25000 count as the max i've seen.

 

OR, the interrupt pin cant interrupt and execute fast enough to count the signal its getting.

 

I'm inclined to think its the IR sensor since the interrupt pin would count as much as it could so i'd still get a high count. Instead at high RPM the count simply drops off to almost zero, implying the sensor cant get a clean "sense" of the LED. 

I'm going to look for an IR sensor with a higher frequency, see if that helps.

 

I also have a new arduino on its way that runs at 48Mhz instead of the 16Mhz of the nano. Possible it may be able to keep up with the interrupt counting if thats the issue.

 

Thoughts?

Edited by Kingbob, 14 February 2016 - 02:36 AM.

[DjOnslaught]

It could be the interrupt isn't able to occur fast enough at max rpm, but could also be the hole is detecting to frequently at high speed and it's reading by the board as single interupts. If you have extra flywheels try one with 2 holes on opposite sides and set it to half the count at low rpm and normal at high, and see what happens

[Kingbob]

I suspect its the IR receiver, i did some testing with a spare one, and if the signal it gets is constant, its output stops. So yeah i figure its detecting so frequently that as far as its concerned its a constantly ON signal.

 

I do have a couple of other IR receiver/transistors to try, see if they're more capable. 

 

I'm half inclined to just tweak the software to say "MAX" instead of the RPM if it exceeds the RPM its capable of reading

[DjOnslaught]

How's the project coming, I'm excited to see the results.

[Kingbob]

Just about there, I cant be bothered swapping the IR sensor, so just gotta write some code so it says MAX instead of dropping to zero.

 

On the plus side, these just arrived:

http://www.sainsmart...mel-atmega.html

 

Works great. Havent used the SD card to load an image yet, but hooked it up for testing and its all good. Does need some extra double sided tape between the LCD and PCB though.

[DjOnslaught]

That's exciting to see, can't wait to see how it turns out.

[Kingbob]

I hate to admit it, but the RPM counter has me beat.

 

It works fine but only when the arduino is connected to USB.

Tried running it all off a higher Ah capacity battery, upped tthe voltage, added in a 5V regulator, ran everything off that. Tried applying power via the usb port, even tried running it off a usb battery. 

 

Gonna have to live with it until i can get an oscilloscope to see whats going on. Might mock another one up on breadboard and test different types of arduinos too.

[DjOnslaught]

Can you post a image of your set up for it?

[Kingbob]

This is the circuit (i think), hall sensors for magazine size detection, one switch for magazine insertion detection, and other switch for trigger.

 

The IR LED/transistor for RPM counting are still connected in the Stryfe, and the code is still there, but i'm not displaying it on the screen until i can get a hold of an oscilloscope to work out why it drops out.

 

The OLED screen also needs a 3.3V source, and fortunately the nano has a regulated 3.3V output.

 

 

Edited by Kingbob, 28 February 2016 - 01:53 AM.

[truglodite]

Kingbob, off the back of the dinner napkin... at 25000RPM a 1/16" hole placed 1" from the axle would give a light pulse similar in length to that from a 21kHz square wave. It already sounds marginal for a 37k sensor in the real world. An o-scope would confirm/deny the inadequate flux/duration theory.

 

Possible solutions... Is a bigger hole possible? How about using a reflective mechanical config with some white/black paint? Another way to get the pulse... like accelerometer or hall sensor? In RC, we usually get RPM from the motor wires themselves (back emf), maybe this can be done for the brushed motors in the stryfe? (a quick google found some info on brushed b-emf lt/dr but here:

https://www.precisio...m-from-back-emf

 

OTOH, maybe it's just a long ISR routine taking over the chip, or a function that requires interrupts inside your ISR? Have you tried using the FreqMeasure/FreqCount libs? I use them for my DIY BLDC RPM sensor (for a small motor dyno project); works awesome... very accurate (just be careful using with certain other timer stuff like, servo & pwm).

 

Hope this helps,

Kev