Solar lighthouse garden ornament - A design that could never work.

About 12 months ago, the long and suffering Mrs Doz bought me a solar powered garden ornament, in the shape of a lighthouse. 

It's got a white 5mm LED, which is situated inside a rotating silver reflector. Quite a nice touch, and more effective than just a simple flashing LED... except it never worked properly. 

There's a push button switch on the lamp housing, which switches the unit on. After dark, the LED illuminates. Once. 

The following day nothing happened. 

It's not worked since. 

So I disassembled the lamp house to see what the fault was. It consists of two parts, the top part consisting of the solar panels, a charging circuit and LED driver, and a lower part with the motor and it's gearbox, and a 600mAH, AA NiMH cell. 

I popped the cover off the motor unit in an attempt to find out what the problem is.... and spot it straight away. The motor is connected via the push button switch, straight across the battery. As soon as it's switched on it will start turning, and eventually discharge the battery. The solar cells aren't big enough to keep the battery charged up enough. What a silly design. 

I was hoping that the LED driver in the top would be able to provide a suitable switched supply to the motor in a similar way to the LED, but alas no, it's got a small flyback converter to provide ~2.1V to drive the LED. 

So, a plan is hatched... 

A separate solar cell, and battery connected by a wire to the motor unit. 

Recently we had to replace another solar light in the garden, after it was damaged over winter. This has yielded a nice solar panel and it's fitted with a single AA NiMH cell, excellent. The battery is tested, and looks to be in reasonable condition. The control electronics in this enclosure are removed (again, it's a flyback converter)

So we need a circuit to charge the battery during the day, and switch on the motor at night. 

The solar cell charges the battery via D1, a BAT43 small signal Schottky diode (a strange choice, but it's rated to 200mA, which is more than the charging current capable of being delivered by the solar cell, and it'll have lower forward voltage drop than a normal silicon diode), which prevents the battery discharging into the solar cell at night. When the cell goes dark, Q1 loses it's base bias via R1 &R2, and switches off, which causes the voltage at it's collector to rise. This in turn switches on the base of Q2, which causes it to conduct and switches on the motor. 

After a bit of experimentation on some breadboard to get the values of R1 & R2 right (this effects the threshold where the unit switches the motor on), it's built up on a bit of perfboard, and fitted inside the enclosure.

After sealing everything up with some liquid rubber, it's taken outside ...

Now just to wait for nightfall...

Further experiments & improvements to the Arduino Geiger Counter

My dad recently returned from a small socially-distant holiday to Cornwall.

"I've bought you a gift, saw this and thought you'd like it!"
"The chap in the shop said it might be a bit radioactive" *

It's a "Radio Compass" from an aircraft. This is used to display a heading to a terrestrial radio beacon. This one's old. Old enough to have a Radium-266 dial. Waving the geiger counter near it proves the point, end-stopping the meter on both the SBM-19 and SBM-20 tubes. It does show a potential limitation in my counter though.. let's investigate....

The original project is here

The count rate appears to be being limited to a shade less than 1000 CPM. by something. It could be the tubes are saturated. It could the arduino is not capable of counting that quickly. It could be the high voltage supply is incapable of delivering that amount of current when the tube is at a high pulse rate, and the HT is falling between counts.

After poking round the high voltage supply, I think we can conclude it's not that ... 

There IS a delay in the tick function of the sketch, and also digitalWrite is notoriously slow.

After modifying the sketch , there's no detectable change, even with that delay removed, which IS still blocking the sketch. 

Looking closer on how I can get the loop to run faster, I'm unnecessarily updating the LCD every cycle, and reading the battery every 5mS ...

 ... this is moved into a non blocking loop counter, to update every ~3 seconds or so ..  

Oh that's fixed it ! I'm now getting a reading of ~30,000 CPM maximum from my radium dial... 

I also needed to tweak the meter movement routine a shade to compensate for the faster loop speed.

The new sketch can be found on my git as usual https://github.com/andydoswell/geiger_counter

*The chap in the shop also told my dad the chap he bought it from had a stack of them under his bed... I'd hate to see what his dose rate is like! 

Garmin HUD & ESP 32 stand-alone module.

A couple of years ago I upgraded my mobile phone, and was dismayed to find Garmin no longer supported my much-beloved HUD (Heads up display), rendering it redundant. It was only 7 years old at the time... is that acceptable product life expectancy? Gutted. 

I seem to remember reading somewhere that the same display was built into BWM cars ... are BMW owners in the same situation?

It featured in my Mini speedo video here. 

Thankfully, someone had reverse engineered the bluetooth serial protocol used to control the device. 

The original work was carried out by gabonator (here), Frank Huebenthal and subsequently by skyforcetw (here). Stunning work. Skyforcetw had even written an android app to interface Google maps to the Garmin HUD, excellent. Except nothing I could do would persuade it to run. 

So I tried skyforcetw's arduino library, and attempted to load it into an ESP32, and tried to modify it for SerialBT. After a lot of debugging and chopping of code from Frank Huebenthal's work, I finally started to get some meaningful information displayed on the HUD. 

So, after this success, a plan was hatched. I just want some meaningful info displayed. I'm not particularly interested (nor capable of) writing something for my phone to run , so I'm thinking about a simple speed display, and maybe some other info.. 

So a UBlox GPS module (this one's an M7, but it will work fine with the cheaper M6)  is hooked up to the ESP32's Serial 2 port on pins 16 & 17, and to the 3V3 and GND pins. 

I recycled my sketch from way back, which was used to configure the GPS receiver in run-time (you can, therefore, use the slightly cheaper module without the battery) and then set about working out why I couldn't get the GarminHud library to run. It turns out that SerialBT's write command isn't quite implemented correctly, so I modified the SendHud function to utilise print instead, which worked.

Version 2 of gabinator and Frank Huebenthal library features a "Down" arrow, which would allow me to implement a GPS compass using the direction arrow function. A gps clock is implemented, a speedometer (in mph, but easily changed to Km/h or knots should the need arise)  and a display of the number of satellites in view (and a warning of no GPS lock) 

There's a slight issue when drawing an "up" arrow. Whatever is written next to the direction display is ignored! This slight bug is overcome by simply writing anything other than "up" twice! 

The sketch (and the required GPS library) can be found on my github here.

The unit is mounted in a box, along with a simple 7805 power supply, and trialled. 

Here's a video of the unit in action. 

... another saved from landfill! 

Wurlitzer 200A electronic piano repairs.

Ah ... another YouTube thing ... a two part thing this time! 

Enjoy