Solar powered AIS repeater, to relay AIS messages from receiver on nearby hill back home via LoRa
Already have an account? Log in.
To make the experience fit your profile, pick a username and tell us what interests you.
Living close to the sea yet in the shadow of some large hills, I am looking to increase my AIS reception coverage by placing a solar powered AIS receiver on a prominent hillside and relay AIS sentences back home via a LoRa RF datalink.
The LoRa broadcasts could be used by other people in the vicinity for their own needs.
I had repeat problems with the SunnyBuddy solar charge controller not wanting to resume charge. As the winter light levels dropped it seemed not to like lower charge input levels and never resume charge even on a sunny day. I grew tired of walking up the hill to reset it, so today collected it and vowed to get rid of the SunnyBuddy issue. It had been a sunny week. The solar panel was outputting about 20V, the LiPo cell was sat at 3.8v but wasn't receiving charge. The teensy was in standby mode as the voltage was low.
The kit has been left on an exposed Scottish mountainside for 6 months of winter. It survived reasonably well, except for a few problems
1) AIS receive antenna support failure
this was an old GRP telescopic fishing rod. The sections were epoxied together but the top section worked loose and collapsed inside. I will back this up with cable ties or drill and screw sections together next time.
2) LoRa tx antenna support failure
The LoRa transmit antenna was a Moxon loop built on 12mm marine ply, and a small radial arm of marine ply lashed to a treestump to make the angle adjustable in the field. Despite being marine ply, the support arm had delaminated and dropped out of alignment. I'll use some blocks of solid treated timber or plastic next time that won't delaminate
3) rodent damage!
Something had nibbled my LoRa coax cable! The copper braid was exposed and the dielectric removed where exposed at the antenna. I'll better protect with hot glue and heatshrink next time!
4) water / condensation ingress
I used a pretty cheap tupperware box with cable glands to house the electronics. I thought it was well sealed but there was 1cm water pooled in it at the end of the time on the hill. My power cable is not circular in cross section so probably wasn't very well sealed, but it was pointing down. Next time I'll use a better box and round section cable so the glands seal. I'll throw in some silica gel packets next time too. I might even drill a hole in the bottom, shield it from driving rain and just let it drain.
The electronics survived the water ingress - mainly because of the following actions:
1) mount the electronics on small standoffs on 12mm marine ply. The water never rose above the level of the marine ply and the standoffs meant the underside of the PCB didn't get wet. The marine ply doesn't rot when wet.
2) spray everything with ACF-50 corrosion spray. Despite being in a condensing environment and visible moisture, everything I sprayed was fresh as a daisy. I missed one junction block and this was quite corroded.
3) solar panel was a semi-flexible type. This took a battering as it was just tied to a treestump to get a proper angle to it. It was a thin-ish aluminium sheet with individual cells on it. The ali plate took a whack from something - presumably a flying branch in a gale, but just bent slightly without cracking any solar units.
1) simple charging
I'm thinking of ditching the SunnyBuddy and LiPo cell.
I want to try just a simple 12v 2Ah gel cell, and a high-efficiency Dc-DC converter. 5v 250mW are under £5 and >90% efficient. The 12V solar panel could go via a solar charger but I think is an OK size just to connect directly to the battery (via reverse blocking diode) and not have any complex battery chemistry worries.
2) watchdog circuit.
I could keep the SunnyBuddy from locking up with a watchdog circuit. I've seen some ICs dedicated to this idea with super low current draw, that the Teensy could just trigger every now and then.
A few weeks ago the box on the hill stopped transmitting. A walk up the hill revealed a slight amount of water ingress to the box (but not touching electronics), a healthy solar panel output, but a dead microcontroller.
Readings on the solar charge controller were:
The battery bank is a 2x18650 LiIon cell, so shouldn't be down this low.
The (not)Charge pin is pulled up to VBat by 10k resistor, and pulled low by the LT3652. Quote datasheet: "After C/10 charge termination or, if the internal timer is used for termination and charge current is less than C/10, the CHRG pin remains high-impedance.
So the charge was deemed to be terminated by current or internal timer.
(not)Fault is also pulled high, and was reading high.
" If no fault conditions exist, the FAULT pin remains
high-impedance"
i.e. no fault.
After disconnecting the solar panel and battery, (not)Charge was pulled low:
" During a battery charging cycle, if required charge current is greater than 1/10 of the programmed maximum current (C/10), CHRG is pulled low."
We have disabled the timer based charge cessation.
What appears to have happened is that C/10 current rate has been met which put the chip into charge complete mode. It then failed to wake again when the battery float voltage drops by 2.5%:
"VFB (Pin 7): Battery Float Voltage Feedback Reference. The charge function operates to achieve a fi nal fl oat voltage of 3.3V on this pin. Output battery fl oat voltage (VBAT(FLT)) is programmed using a resistor divider. VBAT(FLT) can be programmed up to 14.4V. The auto-restart feature initiates a new charging cycle when the voltage at the VFB pin falls 2.5% below the fl oat voltage reference"
I will check this pin next time.
Anyway, after unplugging and reconnecting everything, the battery appeared to be accepting charge, but the microcontroller was (I assume) putting itself into sleep mode as the voltage was too low. I vowed to return with a replacement battery as charging would take a long time with winter light levels.
I forgot about it for several weeks, and then whilst exploring the spectrum with an RTL-SDR, happened across the LoRa transmissions - the unit had come back alive all by itself!
Having a project that sits a couple of miles and an hours' walk up a hillside is not conducive of easy debugging!
AIS message types 5 and 24 (static and voyage data) that contain vessel name are split over two AIS sentences. For some reason I was receiving none of these message types.
Fields that are not full, such as DESTINATION, are padded out, and lead to AIS sentences with long repeating character strings. Example below "222222222" and "88888888888"
steve
!AIVDM,2,1,1,A,55?MbV02;H;s<HtKR20EHE:address@hidden@Dn2222222216L961O5Gf0NSQEp6ClRp8,0*1C
!AIVDM,2,2,1,A,88888888880,2*25 For some reason, something in the transmission chain is adding an extra byte "1" when a string of several similar characters is transmitted.
Example bytes received for 2nd sentence:
33 65 73 86 68 77 44 50 44 50 44 49 44 65 44 56 56 56 56 56 56 56 1 56 56 56 48 44 50 42 50 53
(did you see that extra 1 in there?).
Whether this is the AIS receiver (unlikely), the LoRa transmitter on the hill (most likely) or the LoRa receiver/parser (likely, but less so), I don't currently know as I don't have opportunity to fetch the box from the hill.
In the meantime, I add code to the Python script to simply strip out invalid characters from the payload, then pass to the AIS parser/UDP forwarder.
Due to the 6-bit ascii encoding of AIS data, valid characters in an AIS payload are decimal values 48-87, 96-119. I can afford to just discard invalid characters as the checksum validator in the AIS parsing code will take care of any corrupted bytes; extra bytes introduced in the LoRa datastream are then stripped out correctly and pass validation.
http://catb.org/gpsd/AIVDM.html#_ais_payload_byte_alignment_padding_and_bit_stuffing
The remote box stopped working a few weeks ago - last voltage log was healthy, weather was fine. I have only today got around to climbing up the hill to investigate. I was expecting to see either theft, vandalism by people or wildlife, weather or water damage. However everything was in place and dry still - but why did it stop transmitting positions? I had taken my electronics toolkit with me, fearing the worst.
Vbat: 3.98
Vin to microcontroller: 1.1v . Oh.
Unplug solar panel to check the output (open circuit), which was a healthy 19/20V.
Plug it back in and hey-presto - healthy output to microcontroller again, and a good ~4V going to the LiPo cell....
Conclusion? The charge controller got its knickers in a twist and locked up somehow. I *think* the battery was receiving charge still given that it was on 3.98, so how come the output to the microcntroller was latched so low?
We shall see how long it lasts. I will start researching alternatives to the sparkfun board and perhaps a watchdog service for the output/auto-disconnect and reconnect the solar panel on reboot...
I have ported the receiver code to Python, based on this library for the 868 inair9 LoRa unit, modified for the HopeRF RFM98W on 434MHz on the UPUtronics Pi shield on SPI CE1
https://github.com/mayeranalytics/pySX127x
I will post the code later. Basically you need to
1) install wiring pi http://wiringpi.com/ using git
git clone git://git.drogon.net/wiringPi
2) clone the Mayer analytics library
git clone https://github.com/mayeranalytics/pySX127x.gitinside the pySX127x/SX127x folder, change:
board_config.py
match the DIO0 and 5 pins of the UPUtronics board (DIO0 = rxdone/txdone/cadDone flags, dio5 = data detected flag
class BOARD:
# Note that the BCOM numbering for the GPIOs is used.
DIO0 = 16 # RaspPi GPIO 16 = wpi 27 = phys 36 (input)
DIO1 = 12 # RaspPi GPIO 12 = wpi 26 = phys 16 (input)DIO5 on habhub
#
DIO2 = 24 # RaspPi GPIO 24 = wpi 5 = phys 18 (input)
DIO3 = 25 # RaspPi GPIO 25 = wpi 6 = phys 22 (input)
#LED = 18 # RaspPi GPIO 18 = wpi 1 = phys 12 (output)
LED = 13 # RaspPi GPIO 23 = wpi 1 = phys 33 ( make output)
#connects to the LED on the proto shield
SWITCH = 4 # RaspPi GPIO 4 connects to a switchalso set SPI to CE1 if this applies (UPUtronics board default 1 module population is on CE1 SPI)def SpiDev():
BOARD.spi.open (0,1) #for CE1LoRaArgumentParser.py
change the defaults in the __init__ section to the required frequency, spreading factor etc. This allows the test utiliities to work with yout 433MHz board without specifying further parameters
LoRa.py
change default values for frequency from 868 to 433MHz (search for '86')
you can now run test_lora.py, and in my case, start modifying rx_cont.py at the function
def on_rx_done(self):
That has made logging the battery level to Adafruit.io a piece of (fruit)cake, so now it is logged there as well as thingspeak
I have linked the remote dAISy AIS receiver to marinetraffic
Receiver altitude is approx. 230m ASL, so should be considerably better than the receiver in my loft, although direct comparisons are not possible due to different hardware.
Station coverage and (approximate!) location.
https://www.marinetraffic.com/en/ais/details/stations/910/
Remote unit battery level monitor real-time
https://thingspeak.com/channels/113422
Compare the receiption to the RTL-SDR+Moxon loop receiver in my loft at sea level,
https://www.marinetraffic.com/en/ais/details/stations/1618/
The remote receiver picks up vessels in Oban Bay more reliably (not surprising as it can see over the top of several hills compared to my home station), and sees 'around the corner' into the Sound of Mull better, being able to track the Loch Fyne CalMac ferry on most of its route from Lochaline to Fishnish on the Isle of Mull.
It sacrifices coverage up Loch Creran.
Todo:
* convert daisy to 3.3v operation. I have received advice from Adrian Studer on how to fix excess power drain when operating the dAISy at 3.3v by isolating the 3.3v LDO reg.
* convert the AIS parser script that powers the Twitter feeds @ObanAIS and @ObanSARwatch to accept AIS sentences from the remote receiver.
https://thingspeak.com/channels/113422
once a minute the remote receiver reads the voltage and passes a raw ADC value back to ThingSpeak.
Matlab on Thingspeak scales this (as an exercise in using Thingspeak; the conversion of course could be done either on the Teensy or the Raspberry Pi too!)
source code for the Teensy and the Raspberry Pi has been uploaded to GIT
https://github.com/beinnlora/AIS-repeater (teensy)
https://github.com/beinnlora/lora-gateway (Raspberry Pi)
TL;DR
dAISy AIS receiver www.wegmatt.com https://www.tindie.com/products/astuder/daisy-ais-receiver/
I made up a 5 element colinear antenna for 162MHz - see the project links for webpage for construction details
I'm using a 3.7V Li-ion battery pack (2x18650) so ideally need something suited to 3.3v operation, especially since the Teensy has an onboard 3.3v regulator already.
Adrian Studer who designed the dAISy has been very helpful with information about low power usage. The receiver can be powered at 3.3v but the power consumption (Watts) is lower when powered via 5V rail for some reason.
More details about the receiver:
http://electron-tinker.blogspot.co.uk/2016/04/remote-ais-receiver-part-2-ais-receiver.html
The project is split into two halves
Remote Receiver:
dAISy AIS receiver sends AIS sentences over serial data link to Teensy Microcontroller.
Teensy controller compresses and packetises AIS sentences and transmits them over LoRa data link.
System is powered from 3.7v 2x18650 Li-Ion battery, charged by Sparkfun SunnyBuddy controller and 10W 12V solar panel
Teensy is also responsible for monitoring battery state-of-charge and putting system to sleep if insufficient charge
Base Station
HopeRF module connected to Raspberry PI receives messages over 433MHz LoRa link and reconstructs AIS sentences. AIS sentences then sent over local network to any suitable receiver/chartplotter/AIS service. Telemetry from remote receiver (battery voltage, whether active or sleeping etc) is also received on the Raspberry Pi and logged to the cloud via TheThingsNetwork HTTP API
Michel Kuenemann
Mr. Spriggs
Steve, this is a great project! I hope you were able to get over some of the hurdles you listed. How is it going?