It’s been a while since I etched any boards but I got around to etching the Low Voltage Battery Monitor PCB yesterday.
I did have a slight issue with the 3V battery holder, it was supposed to be mounted on the top but the battery holder that I was using in Eagle was smaller than the real thing so I just mounted it on the bottom. Version 1.1 fixes this issue. Other than that it works well and I can now say is the largest PCB I’ve made.
A quick test video is shown above.
Download Low_Voltage_Battery_Monitor_v1.1 or view the project page.
I highly appreciate your solid approach and academic way of thinking and need your ideas on the following: imagine you are an automotive engineer working on a full time 4wd vehicle with a task to recreate a traction control system which would just visualize wheel spin on a dashboard rather than interfere with engine control or braking system.
Suppose, we have installed hall sensors on each wheels and set 8 magnets on each of the wheel hubs (so that with each rotation of the wheel (2.4 meters of distance) we get 8 impulses.
Now it’s time for a microcontroller. Supposing we have four inputs for hall sensor and one input for the state of the braking pedal. Besides, we have eight outputs for a set of four red and four green LEDs.
If the braking pedal is released, the uC counts the number of impulses within a certain time period, if there is almost no difference in the amount of impulses, it’s okay – all the wheels are turning with equal speed. But when some wheel turns noticeably faster then the others, we turn on the corresponding LED. The more the difference in speed is, the brighter is the LED (probably, using PWM).
Suppose, the driver slows down the vehicle using the braking pedal. In this case the uC behavior is slightly different – it should turn on red LEDs corresponding to the slowest wheels (or may be blocked wheels).
It seems to be easy to explain in words, but when it comes to implementation things become much more difficult. I don’t know what’s the best practice for just checking the impulses (not mentioning PWM for controlling the brightness of LEDs). So, even a simple setup (four inputs, four outputs, no PWM, just turn on the leds for slipping wheels) looks challenging. Do you think i need four external interrupt inputs, or a simple attiny2313 will cope with the task?
Hi, I think you will need to use interrupts however the ATtiny2313 (and I think most other tinyAVRs) only have 2 external interrupts and 1 pin change interrupt. So you’ll need something a little bigger, maybe an ATmega168/328 or similar which has 2 external interrupts and 3 pin change interrupts.
If you already have an ATtiny2313, I would experiment with the interrupts a bit until you need a larger AVR for 4 interrupts for all wheels. If you use pin change interrupts or use INT0 or INT1 in “pin change mode” meaning a HIGH or LOW will trigger the interrupt then you need to account for this. After that all you need to do is keep a count of how many times each different interrupt is triggered.
Other things you might need consider:
– What if the wheel spins too fast that only a HIGH interrupt is triggered and no LOW interrupt gets triggered
– What if there is lots of fluctuations when the wheel spins making the hall sensors detect weird things, this could cause lots of interrupts to occur
– What is the inconsistency in the counter between the wheels when they spin normally
– When should the counter be reset, after 2 seconds, 5 seconds, etc
Well, probably, it’s better to start with the easiest two-wheel setup 😉
The first problem is to define the period of measurements (until when the counter is reset). I’d say it should be a fraction of a second, or at least a second, rather than 5 seconds.
You really think that Hall sensors are that slow? I didn’t get your assumption regarding fluctuations – what do you mean? I believe, considering the number of magnets attached to each wheel, there should be almost no inconsistency in the number of pulses. However, I think we should make allowance that when the vehicle is making a turn, the outer wheel rotates faster, than the inner. For now, I don’t have any calculations for these situations.
In my theoretical setup, at a speed of 60 km/h the wheel makes almost seven turns a second, which makes 56 impulses per second (or 112 impuleses per second at a speed of 120km/h which is probably the highest achievable speed for that vehicle). This makes less than 1 impulse a second at a speed of 1 km/h.
Now, as for the algorithm: say, I have two INT pins and two variables: l_count and r_count. On each interrupt I am increasing corresponding variables by one. Then I need a timer which should make a comparison, and should the difference be greater than allowance, it should turn on corresponding LED and reset the counters.
Now, there should be another timer to turn off the LEDs, and I don’t know where should it be.
Besides, I need an assessment if I have enough processing resources for this basic task.
Things become much more difficult for a four-wheel setup: I don’t know how to make a comparison in that case. Considering there might be up to 112 impulses per second per each interrupt, is there enough time to make comparisons?
In regards to hall sensors being slow – I’m not sure I’ve never played around with one.
About the fluctuations, I was thinking that if the magnetic field isn’t strong enough and the wheel is spinning fast enough then maybe the hall sensor would either not detect the wheel passing through or detect a very faint signal which could cause it to trigger the same interrupt multiple times – but again I don’t know I probably am wrong, only way to find out is to test it.
Your algorithm sounds good, for the timers they don’t have to use the real AVR timers, you could just use delay because your program is all interrupt based that nothing needs to happen in your main code.
Your code could look like (assuming no PWM and that the LEDs will stay on for 1 second and that the comparing of counters happens after 1 second too):
while (1) { delay_ms(1000); turnoffallLEDs; (If left wheel spins faster than the variance we gave) { turnonleftLED; } (If right wheel spins faster than the variance we gave) { turnonleftLED; } resetcounter; } ISRs{}If your AVR is at 1MHz (factory default), that’s 1 microsecond per clock cycle or 1000 clock cycles for 1 millisecond. At the maximum 112 impulses per second that’s 1 pulse every 1.8 milliseconds. If your interrupt routines take say 20-50 clock cycles each pulse x 4 wheels = 200 clock cycles max, so you have 1600 clock cycles to spare. So yes even at 1MHz the AVR can cope. At say 8MHz, it’s 8x faster, you have 8000 clock cycles to play around with for 1 millisecond.
Your calculations look quite promising!
The algorithm for a two-wheel setup is also quite understandable and viable. But I am not sure I will have enough default machine time to compare four counters at a time (I even cant imagine what should they be? How much cycles does it usually take for a simple comparison? Four ‘if’s? What if I get counters increased while performing those comparisons?)
As for Hall sensors – ever wanted to play with them? Actually, don’t know how to use them. And there are various kinds. It seems I’ve got HAL506UA-K-2-B-1-00.
(http://kazus.ru/nuke/docs/IMET/000055.pdf)
If I am lucky, I’ll be able to test how it works this weekend. I’ll check the operating distance (one more problem to consider – how far away the magnet could be without affecting reliability), and ideas for mounting the sensor on the vehicle.
Hopefully, by that time I’ll know how to use it at least just to turn on the LED (without microcontroller)
For how long it takes for a simple ‘if’ comparison the AVR will need to load both variables being compared to the storage registers (1-2 clocks each) and then perform the compare (1-2 clocks), in any case it’s not a lot.
You can actually check after you compile your code, if you use run “avr-objdump.exe -S main.elf > asm.txt” on your compiled .elf file. If you open up the asm.txt you will see the source code mixed in with the assembly code. Then you can check the AVR PDF and it shows you how many clock cycles each operation takes (“Instruction Set Summary”). An easier way is to load the .elf file into AVR Studio and run the simulator then you can see set breakpoints and monitor the clock cycle counter.
A good question about the counters being increased when doing the comparisons, it can happen but you can easily assign the values to temporary variables and compare those as they won’t change. When using variables with-in interrupts you need to assign that variable as a volatile, e.g. volatile int test = 0;
An interesting project you have here 🙂
this is great! I know I could really use one of those for checking batteries before placing them in some of my gadgets