Replace the Lead Acid Battery in your Ride on Mower with LiFePO4 - Progress Report

Just a quick update now that the battery and BMS system has been in place for several months. 

So far nothing untoward has happened. 

1. Those tiny 14Ah cells are still in service and kick the mower over without drama. 
2. The BMS has not blown up from the starting currents
3. The BMS algorithms were tinkered with the battery now reaches about 95% charge before being disconnected.

Now that the system has proven to be robust I'll wait for something to fail before touching it again.The only downside is I can no longer avoid mowing the lawn due to a flat battery!

If you're interested in more details you're welcome to contact me.

Serial Data Transmission with RF - Improved Hardware and Range Testing

A better receiver is justified. 

The build quality of these super regenerative receivers, like most of the Aliexcrement or Crapbay stuff from China, is woeful and I have little confidence will work on an extended basis. I had two receivers. After getting them working due to manufacturing faults one stopped working again very quickly. The second unit works but appears to suffer from dry joints because the performance is inconsistent.

During development I discovered that the receiving module is a super-regenerative type. I was able to confirm, as expected, that it generates noise on 433.2MHz which prevents multiple receivers from being located close together. But the biggest concern I have is temperature stability. While it doesn't matter so much when located in-side a house, it does have implications for being located outside. As ambient temperatures change, say from 0 Celsius to 35 Celsius, the frequency to which the receiver is tuned will shift. That will reduce the sensitivity since the transmitter is in comparison stable. So not only do receivers need to be physically spaced apart they also need to be in a relatively stable temperature. 

Search for 433MHz receiving modules on your favourite site and there will be plenty to chose from. Get one with a crystal like this one and you should be far better off for the few extra cents.

 

However, not all modules work. The one pictured above was purchased from LCSC. A mediocre datasheet did not help get it working. A typical decoded data stream is shown below:

I gave up trying to work out why these didn't work when the second one I pulled from the packet had an aerial that was swinging in the breeze.  My suspicion is the data rate was too fast for the receiver chip.

I trawled my junkbox and found another receiver module. The MPN was RX520. Like the module discussed above, the output also tended to idle in a high state. So I altered my code slightly to account for this.

Then, in a real twist, I discovered that the for this second superheterodyne module the first pulse following the start pulse is slightly longer than you would expect. Perhaps an artifact of AGC action since logging strong pulses and weaker pulses showed a clear difference. This is not an ideal situation. However, adjusting the 1/0 threshold allowed range testing to begin.

A preliminary range test was made. The transmitter used a vertical antenna, but no ground plane, and was located on the ground. The receiver used a 13cm piece of wire. Neither was ideal. But this combination would work reliably at 35m line of sight when no interference was present. The interference was evidenced by the flashing led cycling on and off correctly for up to 4 seconds, then it would "freeze" for a random length of time before working again. 

On balance I'm satisfied with the result. I have a list of further potential enhancements which might improve the robustness of a link. My first real application may not require them so I'll push on with that application.

Testing Anko CR2032 cells in Joule Smasher Led Flasher - Update 1

 

It's now been 3.5 days and the Anko CR2032 cells appear to be a good purchase. The cell voltage has dropped to 3.073V. The used cell hit this voltage after 2.1 days and went on to last for 104 days. 

Since the worst of the no-name rubbish from Crapbay lasted 21 days I'll leave it a till then before publishing a further update. At that stage the graph comparing the 4 tested CR2032 cells should be striking.

However, initial results are so good that I today installed one of these cells in the car remote. I'd been holding off because car remotes are not designed to be popped apart too often.

Serial Data Transmission with RF - Range Testing

To recap, I now have a receiver with very little noise on the data out pin between actual packets. I have a transmitter alternatively sending two characters 500ms apart. And I modified the receiver board to toggle a LED depending on which character was received.

My thinking was that I could walk away from the transmitter and watch for the LED to start blinking erratically or cease blinking at all. Then I could make some changes and see if the range got better or worse.

I had done something similar with nRF24L01 modules some years ago and that had convinced me 2.4GHz wasn't suitable because in real life the range was too short to be useful.

My initial test showed a range of only 11m across the workshop. The decoding was reliable right up to the doorway. The following day I put the TX unit on the ground near the door and the RX unit back on the bench to look at the data stream. Rock solid. So I iteratively moved the transmitter out of the workshop. At the property boundary it was now, according to Google Maps, 27m from the receiver and down a decline. But still in a direct line through the doorway.

The blinking was steady indicating no errors. 

 

What is noticeable is that as the signal strength drops with increasing range the pulses get narrower. 

The edge of range was when the transmitter was about 32m from the receiver and now screened by the workshop wall. At this point the light began blinking erratically. Looking at the received data stream it was obvious why this was. 

The pulses were getting so narrow that either the start pulse is outside the allowed range weak or, as seen from the second last pulse above only just hitting 2V, the pulses are not hitting a logic high level.

A quick check: Assume Vcc=3.7V. Logic high for the micro is say 70% of Vcc or 2.59V. The LM358 can swing to perhaps 1.2V of Vcc, or 2.5V. So logic high is not being met. 

At 5v the problem goes away. 

Three possible fixes: 

1. Replace the LM358 with a R2R output opamp.
2. Add a pull-up resistor to the data line.
3. Use two LiPo batteries and the onboard regulator.

The third option is expedient for range testing purposes but adding a pull up resistor is no harder and maybe relevant to a battery powered receiver.

I added a 10k resistor from the data line to Vcc and the high logic level is now being met. I didn't persist with this because the following day when I went to do the range testing the noise was again present. Given the hardware issues with this receiver model I decided to suspend work since I now have a better receiver board.

 

 

Footnote for those landing here via Google Search:

My suspicion is that a lot of people trying to get these receivers to work on a LiPo battery had issues with this. This problem is exacerbated when both the ATMega and Rx unit are running at 3.3V. So if you landed here trying to work out why your Arduino project isn't working now you have a hardware issue to consider.

Testing Anko CR2032 cells in Joule Smasher Led Flasher

I first wrote about how bad no-name CR2032 cells are here. As well as proving to be rubbish in the Joule Smasher Led Flasher (JSLF), they also proved short lived in a car remote. Which made me wonder if the JSLF could be a useful way of testing different brands of CR2032 cells.

Since I needed a new battery for the car remote I brought a pack of 4 Anko CR2032 cells from K-mart.  Almost immediately I could see how much better they were than the no-name rubbish from Crapbay. The best of the no-name cells had dropped below 3.2V within 2.5 hours.The worst example was almost immediately below 3.2V.

However, the Anko cell was still above 3.2V at the 6 hour mark. Present indications are it will hit 3.2V at the 7 hour mark. The next few days will give me some confidence in my purchase!

Automatic Backup Lighting - V2.0 Amendments

Some small changes:

use a LED to indicate the presence of a charging voltage

replace the LM317's in the charging circuit with a 5V regulator feeding a 3.4V regulator. Current limiting is now via a resistor between the 5V rail and the 3.4V regulator.

Used hardware to control if charging circuit is connected to battery instead of software.

Serial Data Transmission with RF - Receiving Notes Part 3

In preparation for range testing I made a leap of faith and decided to improve the speed of the receiver code with still more assembly code. I felt the code was fast enough. However, but I wanted to be sure that if I sent two packets with a short gap, say 2ms, that the receiver would be ready 2ms after the previous packet finished

It was a relatively smooth exercise. That's testament to how the design choices in STM8 eForth set it apart. And the power of Forth itself. Interactively testing at the console is so far in front of a "compile upload debug" model many languages require.

So after fetching 9 pulse lengths (PL) I did a thumb suck on how long it would take:

9 PL x 10 clock cycles to process each PL = 270 clock cycles.

Say 20 clock cycles to use the byte received

Clock speed of 16MHz means 290 clock cycles equates to ~18uS

So even if the next byte starts 50uS after one finishes then the micro should be ready. Now I'm comfortable that I can send multiple bytes with a short delay and missed packets are the result of being out of range.

 

Lesson learned - the preamble should never be a start pulse.

I had a hunch, given the strange stuff going on today, that the soldering of the receiver to the base board needed touching up. That seemed to transform the receiver and now there was no noise between bytes on the data pin.  I thought that was a real win. 

While the noise returned, which really annoys me, it turned out to be masking another issue. As it turn out, grabbing the 9th pulse when there was no noise meant the preamble from the following packet was grabbed. So the time it took to  process the 9 pulses, while short, meant that the measured pulse length for the next start byte was just outside the window I had allowed. So that byte was skipped altogether.

It took me some time to work this out. The grabbing of 9 pulses was a relic of when a packet commenced with 2 start pulses. Far better, in my opinion, to simplify the processing of received pulses to only have one START pulse. That way you don't have to deal with the possibility of an extra start pulse.  So far better that the preamble is nothing like a start pulse.