eChook Nano Code V2.5 (Beta)

Code V2.5 has been in the works for a while, and it’s now at the point where it’s worth writing up and putting in front of teams for testing. This is a beta release – not the default download yet. If you would like to test it and give any feedback that would be much appreciated!

What’s new?

Period-based RPM and speed sensing
Wheel and motor speed are now being measured from the time between magnet pulses, using hardware input capture on the Nano Every rather than timing things in software in the interrupt routine. This is a more direct measurement than pulse-counting, especially at low speed where there are few pulses to count in a given window. Previous attempts at this suffered significant jitter and as such weren’t published – the new implementations appear much more robust in bench testing.

The hardware and software implementations are now properly split per microcontroller, so the 328P and the Every each get an implementation suited to their own hardware, instead of one routine compromising for both.

Analogue reading accuracy
It wasn’t broken, but there was room for improvement – three fixes, all affecting every scaled analogue reading – battery voltages, current, throttle, thermistors:

  • The 5V rail reference is now measured before it’s used to correct that cycle’s readings, rather than at the end of the 250ms block. Previously every reading was corrected using a rail measurement from the previous cycle, which matters because rail sag under load is exactly what the correction is for.
  • Readings are now oversampled instead of taken as a single sample. On the Nano Every this uses the ADC’s built-in hardware accumulation, so 16 samples cost one conversion sequence instead of 16 separate reads; the 328P loops the reads in software. This recovers some resolution on signals that are often fairly noisy.
  • The code previously mixed two different ADC conversion conventions between channels (dividing by 1024 in some places, 1023 in others) and truncated instead of rounding to the centre of the input band. Everything now goes through one conversion helper, removing a small but consistent low bias on every reading.

5V rail measurement and internal temperature sensor on the Nano Every
The 328P has a neat trick for measuring its own 5V rail: point the ADC mux at the internal 1.1V bandgap reference, but leave the ADC’s own reference set to VCC. Since the 1.1V is fixed, the ratio between that reading and the ADC’s full range tells you what VCC actually is – all self-contained within the ADC.

The Every’s ATmega4809 doesn’t have that option – there’s no way to route the internal 1.1V reference directly onto the ADC’s mux. V2.5 gets there by a slightly longer path through the Analogue Comparator peripheral instead. The AC has its own 8-bit DAC ladder, and VREF can set the top of that ladder to the internal 1.1V reference rather than VDD. Set the DAC to a known code, then point the ADC – still referenced against VDD as normal – at the DAC’s output node (DACREF) via its mux instead of a pin. Comparing the ADC’s reading of that known fraction of 1.1V against VDD gives the same ratio the 328P gets directly, just routed through one extra peripheral to reach it. It averages 8 samples for about 2.8mV of resolution, restores every register it touches afterwards so it doesn’t interfere with anything else using the AC or VREF, and falls back to a fixed calibration value if the result looks implausible. I wish I could claim credit for this workaround, but it was AI that worked out the process!

Diagram comparing how the ATmega328P and ATmega4809 (Nano Every) measure their own 5V rail: the 328P reads the internal 1.1V reference directly on the ADC mux, while the Every routes it through the Analog Comparator's DAC ladder to a DACREF node before the ADC samples it
Same principle, some extra steps on the Every: the 328P reads the internal reference directly, the Every has to route it through the comparator’s DAC ladder first.

The internal temperature sensor on the Every has also been improved as part of the same work, following the datasheet procedure and applying the factory calibration values instead of the rough approximation it was using before.

Testing

The RPM/speed rework and analogue accuracy changes haven’t had a proper run on a car yet – just bench testing – this is very much a beta release right now, but in time for the second half of the season for teams willing to try. If you’re happy to flash it to a board and put it through it’s paces, I’d like to hear how it goes – any bugs found will be patched for the final release.

Get in touch in the comments here, or drop me an email at [email protected].

Leave a Reply

Your email address will not be published. Required fields are marked *

I accept the Privacy Policy

0
    0
    Your Cart
    Your cart is emptyReturn to Shop