HABAXE - High Altitude Balloon Tracker for PICAXE.

[srnet]

One of the things I had been experimenting with in 2012 was using a PICAXE and RFM22B as a balloon tracker.

I built a tracker that was light enough to use party balloons, heavy payloads need large balloons and lots of expensive helium (or hydrogen!). Small balloons are low key, simpler to launch and don't need CAA approval. These are known as Pico balloons and some of the solar powered ones have gone hundreds and thousands of kilometres.

My original tracker design was called 'PongSat';

http://www.picaxeforum.co.uk/showthread.php?22369-Picaxe-pongsat

It worked, but I got distracted on other 'higher' projects, and never had a chance to fly it more than a few hundred meters.

I have been looking at this again recently, wanting to make a more versatile tracker that you could fit with one of the very small digital cameras.

My idea was a prototype PCB about 100mm x 25mm and see if the basics of a tracker can be fitted with additional connectors\pads to allow for extra PCBs to be added to hold cameras or experiments. The radio and antenna would be on the bottom of the PCB, the GPS on the top where the balloons are attached.

The basics of the tracker to include;

PICAXE, 28X2 or 40X2, because there are 4 program slots, and dual SPI\I2C interfaces

GPS, Ublox 6 or 7 because they are small and light, PCB antenna

RFM22B transceiver for up and down link, small light cheap, frequency agile, proven to work in space !

A small Lithium Ion or Polymer battery, good range of sizes and available.

Regulator, to ensure stable operation of Radio.

Watchdog and power down circuit, to protect against program crashes or radiation problems.

Current monitor, to detect possible latch ups.

Memory for storing balloon track, if no-one but you is tracking the balloon, you would want to know the track when you get it back.

Expansion connector with I\O and SPI\I2C bus connections, for 'experiments' and other power supply options.

The PICAXE basic code and other stuff can be found here;

https://www.dropbox.com/sh/ddtjsxkr2kcph2g/AAAEiojS9xv_mSmcCUlns38Ca

 

[TimHAB]

Hi there srnet.

I am very interested in your PICAXE HAB balloon tracker. I have been monitoring spacenear.us and very keen to have a go myself! Unfortunately the last coding I did was Sinclair BASIC way back in the time so this appeals to me a lot! I have played with Arduinos and Raspberry pi but we dont get along very well! I like BASIC and it did all I ever asked of it! I am liking a lot what I have read about the PICAXE and think a hab project would be a very interesting project to get into and learn.

I hope to hear from you and learn more of your PICAXE balloon tracker.

Best regards.

Tim

 

[srnet]

Its coming along, although slowly, as I dont work from home anymore..........

Hope to have the draft PCB done in the next week or so, then a 2-3 week delay for them to arrive.

The initial PCB should end up at 100mm x 25mm, using a 40X2, with an expansion connector.

If the PCB works, then the code should not take to long as most of its working already.

One option I hope to add is a GPS engine that calculates the distance and direction between two sets of LAT and LONG. I wrote code for this some time back for a native PIC, it should fit in one of the 14pin SOIC devices, so not big or heavy. The PICAXE code for a distance and direction calculation does work, but its limited to about 60km in the UK.

 

[TimHAB]

It all soundts very interesting indeed. Please keep me up to date on your project as I would be very interested in building one as I would like to launch a pico baloon and trac it. Good luck with it and please keep me posted! If I can help in any way please let me know! Also are you using a mode that you are able to track your tracker on dl-fldigi and spacenear.us?

 

[srnet]

Also are you using a mode that you are able to track your tracker on dl-fldigi and spacenear.us?

For the Lost Model Locator project I did (28X2) that does put out the GPS location and various bit of data as FSK RTTY, 100baud, in the format that FLDIGI HAB should support (a GPS NMEA string). Although the HAB guys prefer to use a better checksum, but the simpler one I used should be supported.

The same code is used to send the $50SAT FSK RTTY and that seems to work fairly well..........

 

[TimHAB]

Thank you, thats great news! I am just waiting for an antenna to arrive. I have an ICOM PCR1000 and I am going to set up a tracking base station very soon. I have another PCR that I am going to try and set up a chase car to. Just need a payload to learn about and experment with. All exciting stuff!

 

[srnet]

I have tracked a few of the UKs HABs using a Funcube Dongle, LNA and home brew Quadrafilar Helix.

 

[TimHAB]

Funky antenna!

 

[srnet]

It all seems to fit on a 100mmx25mm PCB.

The choice of PCB size means it will easily fit on a standard sizes 100mm x 50mm, which cost around £14 for 10.

Default track size at 6mil is small, but I have not seen any PCB quality issues with tracks as fine as this.

The SMT resistors being low profile are on the PCB rear, with a thin foam cover you will be able to attach a Lithium Ion or Polymer battery to the rear.

Still some changes to be made, holes for the piano wire antenna and radials, mount holes, holes for tie wrapping a battery on. However, as its now routed complete, the optimisation has freed up quite a bit of board space by reducing track lengths and vias, so small subsequent adjustments and additions are a lot easier.

The expansion connector is the two rows of 0.1" pads on the PCB edge, they have the same layout and connections as a DIL 40X2, and will allow a daughter board to be fitted or a bit of 0.1" strip board to allow for testing of other stuff.

Initial idea is to address the GPS via its I2C interface, thus freeing up the hardware UART for other stuff, but the board has connections for using the GPS via UART also.

 

[TimHAB]

Looks very neat.and well thought out. This is a fantastic project you are working on and I think it has great potential and is very exciting indeed. I like your idea of the daughter board. Perhaps a camera module with a micro SD card for storage?

 

[srnet]

Perhaps a camera module with a micro SD card for storage?

That was the idea ...........

One of the keyfob cameras or similar, hacked so the PICAXE I\O can turn the camera on and take pictures on demand.



Most of the very small cameras use micro SD cards

 

[TimHAB]

I have seen somewhere how to mod an 808 keychain camera to be controlled by a microcontroler and some models of that camera have a micro SD slot.
Just found the link for you. Hope it helps!
http://nerdfever.com/?p=1215

 

[srnet]

I have tested the routines that drive the radio (RFM22) for Morse, data packets and FSK RTTY.

I am using the second SPI\I2C interface on the 40X2, via peek and poke to the PIC registers direct, as the HSPISETUP command does not support the second SPI\I2C interface.

It all appears to work fine, so this then frees up the standard SPI\I2C interface to be used for I2C, so I can mix SPI devices (RFM22 radio and Flash memory) on the same PICAXE as I2C devices (BMP085 pressure sensor).

It even works OK at 8Mhz, so no need to run at higher speed.

 

[TimHAB]

This is sounding like a very versatile and capable tracker. Very exciting indeed! I presume the morse is for callsign rather than telemetry. I have been intrigued with the feld hell and slow hell modes recently. Seems to get very good range. particularly slow hell, but you have to enter the recieved message manually on the tracking software. I think this is a fascinating mode though. Keep up the great work!

 

[srnet]

I presume the Morse is for call sign rather than telemetry. I have been intrigued with the feld hell and slow hell modes recently. Seems to get very good range. particularly slow hell, but you have to enter the received message manually on the tracking software. I think this is a fascinating mode though. Keep up the great work!

Nope, the Morse can optionally be used at slow human readable speed for sending basic numbers, or in fast mode (120WPM) also. It works, and provides a means for those with only basic equipment to receive data form a tracker.

There are a lot of ‘intriguing’ modes out there but can they be made to operate in a battery efficient mode from an airborne tracker using a very small and cheap transmitter ?

The limitation on distance when operating in the license exempt UHF band, has more to do with the radio horizon, than it has to do with mode.

10mW of FSK RTYY from the RFM22 should have a line of sight range of around 700km with an omni antenna but for that to be visible radio wise the balloon would need to be an altitude of 30km. So even if you had a more efficient mode, you wont hear it if the balloon were at the same height, but further away, the balloon is beyond the radio horizon.

 

[TimHAB]

Thanks for the explanation. I think that is whyI find it so fascinating! There are so many elements to it that you are constantly learning and gain experience about radio, electronics the weather and all kinds of interesting stuff. And then you understand a bit more and think what if? and start the process all over again. I would very much like to build one of your trackers and launch a flight at some time, as to be honest the level you have taken it to, is far beyond what I could ever realistically achieve or have the knowledge and experience of. However I find the PICAXE way of doing things very satisfying and your project inspires me to develop my own much simpler but fun pico HAB experiments. Using your boards for serious Pico HAB flights, perhaps after launching and gaining more experience by launching and recovering more simple experimental flights to learn from. You mentioned the use of morse as being used for human readable and good as a digital mode at faster speeds. I like the idea of human readable modes as I think that there potentially might be more people recieving the signals than are activly reporting to tracking software on the net and so human readable data might provide a wider "audience" that might be able to provide QSO's on long duration flight to areas where there are no online tracking stations set up. All exciting stuff!

 

[srnet]

Here is the test program used to show that the RFM22B can be driven for all available modes on the second SPI interface.

It first sets up the RFM22, displays the set frequency by reading back the frequency setting registers, sends 'HABAXE' in slow then fast Morse, sends a string of numbers as a NMEA format style ASCII FSK RTTY string at 100baud, then sends the same data as a telemetry packet.

All decodes just fine when the reciver is a Funcube Dongle and using FLDIGI software.

 

[srnet]

PCB Ready to Go

 

[srnet]

Here is my first go at the HABAXE software. Its a work in progress, and at the least I need to go through it and test the error trapping.

For now it just transmits in FSK RTTY and a slow FM Morse beacon, but I guess thats all a lot of people will use.

The data format format is compatible with UK High Altitude Society recommended format;

$$HABAXE,sentence_id,time,lat,long,altitude,speed,bearing,temp,battmV,flags,*CHECKSUM,CR,LF

Where 'HABAXE' is the TX identifier.

Sample output decoded from HAB FLDIGI;

$HABAXE,10,17:17:18,5250.6370,-00251.4710,46,0,0,20,3824,519,*1A

Its running on a PCB I did for use as a ground based reciever for the $50SAT project, and its not exactly big. The software will easily convert to the lighter hardware based on the 40X2. The program is in two slots, the transmitter is in slot0 and is 1617 bytes out of 4096, the GPS data collector and formatter is in slot1 and is 2346 bytes out of 4096, so just 24% of the available code space used so far.

Next is to add is the data telemetry, and make a reciver work on that too.

 

[srnet]

I ran some tests on the software, having added the data telemetry and the fast Morse sending.

The FSK RTTY takes around 9 seconds to send, at 100baud, current consumption during this time is 35mA.

The GPS I was testing with, the Mediatek 3329, has an enable pin, and once the GPS has achieved lock, you can disable it and the current drops from about 45mA when running to microamps when disabled. It then needs about 4-5 seconds of power to re-establish lock.

With it all left running, sending the RTTY message every 30 seconds or so, a 420mAhr Lithium Polymer battery (12g) ran the tracker for around 14hours. The idle current is around 2.5mA, so has no significant bearing on the battery life.

By increasing the FSK RTTY to 200baud, the battery life should increase to about 24 hours, not bad for a 12g battery.

Of note is the data telemetry, that sends the same data as the FSK RTTY, but it manages it in about 300mS, so the power savings are significant. To track with the data telemetry, you need to build a receiver and use a portable yagi, see picture, that combination should give a reception range of around 40kM. I have a low noise amplifier (also portable) which will extend the range by a further factor of 3 or 4.

 

[srnet]

PCBs arrived yesterday, looking good, 6g, should have a chance to assemble one this coming weekend.

Code is virtually complete.

I made some changes to the way the RTTY was complied, I was concerned that GPS failure in flight would cause the tracker to stop transmitting data or send corrupt data that the UKHAB system would not recognise. Problem is that the GPS info, location, altitude, speed and track, is in the middle of the payload between the header, sequence number (which changes) and tracker data such as battery volts, temperature etc. The GPS part can vary in length too.

So I arranged it that the last GPS data is kept in a RAM buffer, and only updated when the GPS gives a current valid fix. If the GPS fails, then the old GPS data is used but the other stuff (sequence, battery, etc) keeps updating. Thus if there is a failure at least the last good location is sent, together with other info and an error flag byte that may give a clue as to the cause of the failure.

I then turned my attention to the CRC for the outgoing RTTY, I was using the simple byte XOR CRC the same CRC that is used for the NMEA stuff from the GPS. Its supported by the UKHAB system, but the CCIT 16bit CRC is far more robust, and is preferred.

The calculation for the CCIT CRC is not one of those things a PICAXE is ever going to do very quickly, I timed the calculation and each byte takes 10.5mS at 16Mhz to add to the CRC. Now for a payload that could be 64 characters (or more) then the CRC for the entire payload could take 650mS or so to do, which is a lot of wasted power, as during this time the transmitter is on.

However, as always with PICAXE, you just need to think of the problem in a different way. The RTTY will be going out at 200baud, so a single bit is 5mS. The CRC calc takes 10.5mS per byte, which is the same time as the required 2 stop bits. So all you need to do is run the CRC calc after the byte bits have been sent, no need for a seperate stop bit delay, no wasting power.

 

[srnet]

It works.

At least in its basic form and talking to the GPS via the serial interface.

Wieght of PCB, including the GPS, 9.3g. So if you add a 12g Lipo, that takes you to 21g, so a large foil party ballon should provide plenty of lift.

For a minamalist tracker the PCB is oversize and could be reduced by about half, which would cut the weight by 3g or so.

Next, dualing with the BMP085 pressure and temperature sensor.

 

[kriekcj]

Dear srnet, how can i get one or more of the prototypes?
regards
C,

 

[srnet]

Dear srnet, how can i get one or more of the prototypes?

You cant, they are not for sale.

This is still a prototype anyway, there are still a few things to get working.

I might sell the PCBs, if there is any interest, but this is very much a DIY project, not a commercial one.

 

[srnet]

Have the BMP085 pressure sensor working so the I2C bus side must be OK.

Not sure if knowing the air pressure is worth all the effort, its a tricky thing to solder, and the code to read it quite long.

Not too bad as a temperature sensor, but a DS18B20 might be a better bet, easier to assemble and easier to code.

The performance of the Ublox GPS with the tiuny antenna is surprisingly good, adequate for the purpose certainly. The GPS does power down fairly well into low power mode (a few uA) and re-aquires in between 2-5 seconds, which is just as well, it does seem to use a bit more current that the Mediatek 3329.

Next, I wonder if you can talk to the GPS over I2C ?

 

[srnet]

Well, you can talk to the Ublox GPS over I2C, or indeed SPI.

However its not quite as useful as it seems, when compared to the background receive that the X2 does on the UART port.

The GPS does buffer the characters interanally but to parse the GPS sentance you really need to copy from the GPS internal buffer to scratchpad, then ge tthe data out you want. Background serial receive does this all for you of course, automatically.

The implementation of the I2C and SPI bus interfaces for the Ublox only allows you to configure the GSP via the normal UART style commands, there is no register centric configuration available which is a significant shortcoming. The must somewhere inside the GPS be a bit or byte which turns off the various sentances, but you cannot write to these registers directly.

And here is some code, it reads the GPS buffer over I2C, and when there is enough characters ready, prints the buffet to the terminal.

'UBLOX Neo 6 via I2C V1.bas
'Stuart Robinson June 2014

#rem
Reads the UBLOX NEO 6 GPS via I2C interface
#endrem


#terminal 9600
#picaxe 40X2
#no_data


SYMBOL GPSPOWER = b.3 			'Drives power switching MOSFET for GPS supply
symbol PXLED =  c.1             	'Pin with PXLED on it


symbol TX = a.4				'Serout pin for always sending output to terminal
symbol TXGPS = c.6  			'Serout pin for GPS output
symbol baud = N9600_16  		'Baud settings for terminal output at 16Mhz
symbol baudGPS = T9600_16  		'Baud settings for GPS output at 16Mhz

symbol var1 = b4
symbol var2 = b5 
symbol character = b6
symbol loopv1 = b7
symbol wvar1 = w27
symbol loopv3 = w26 



main: 

setfreq M16

high PXLED					'turn on LED to show program is running

low GPSpower				'turns on the power to the GPS

pause 2000					'allow terminal to be ready

hi2csetup i2cmaster, %10000100, i2cslow_16, i2cbyte  'set up I2C interface, address $42 (shifted left one bit)

gosub configviaUART

serout TX, baud, ("Starting UBLOX Neo 6 I2C read test",CR,LF)


loop1:

	hi2cin $FD,(var2, var1) 				'read the number of bytes available in buffer

	wvar1 = var2 * 256 + var1

	serout TX, baud, ("Buffer bytes available ",#wvar1,CR,LF) 'print out byte avaialble in buffer

	if wvar1 <> 65535 then     				'return values of $FFFF seem normal, so ignore them
		if wvar1 > 250 then				'if there are more than 250 bytes avaialable, then print them
			gosub printGPSbuffer
		end if
	end if
	
	pause 500

goto loop1



PrintGPSbuffer:
	'print the contents of the GPS buffer to terminal
	for loopv3 = 0 to wvar1
		hi2cin (character)
		serout TX, baud, (character)
	next loopv3
	pause 6000
return	


configviaUART:
	'setup GPS, turn off various sentances
	serout TX, baud, ("Configuring GPS")
	serout TXGPS, baudGPS, ("$PUBX,40,GLL,0,0,0,0*5C",CR,LF)
	serout TXGPS, baudGPS, ("$PUBX,40,ZDA,0,0,0,0*44",CR,LF)
	serout TXGPS, baudGPS, ("$PUBX,40,VTG,0,0,0,0*5E",CR,LF)
	serout TXGPS, baudGPS, ("$PUBX,40,GSV,0,0,0,0*59",CR,LF)
	serout TXGPS, baudGPS, ("$PUBX,40,GSA,0,0,0,0*4E",CR,LF)
	serout TX, baud, (" Done",CR,LF)
return

 

[srnet]

The Flash RAM is working, its 4Mbyte, so with the standard payload as sent out by the RTTY being a 64byte block, there is enough space for 65,536 entries. At approx 3 entries per minute (max) there is enough space for 364 hours of logging.

I did some current measurements at different clock speeds, HABAXE does not need to work very fast so it might be worth considering altering the clock speed to save power.

I put the PICAXE into a simple loop, printing a message to the terminal so I could check the processor speed was as expected;

Internal 1Mhz, 1.66mA
Internal 2Mhz, 1.82mA
Internal 4Mhz, 2.23mA
Internal 8Mhz, 2.95mA
Internal 16Mhz, 4.41mA

External 16Mhz, 4.16mA
External 32Mhz, 7.12mA
External 64Mhz, 12.94mA

Sleep mode 0.75mA

So in fact running at slower speed is not a good idea, if a task you run at a default speed of 8Mhz takes 1 second, and consumes 2.95mA in that second, running at 1Mhz will take 8 times as long, using the equivalent of 13.22mA, or 4.5 times the power.

On the other hand if you run the same 1s/2.95mA task at 64Mhz, it completes in 1/8th the time and uses the equivalent of 1.6mA.

There does not seem to be a lot of point operations wise in going above 16Mhz, although a resonator will be used as the FSK RTTY needs to stay accurate over large temperature variations. Although 64Mhz would be very handy for spooling out the data stored in Flash memory.

 

[srnet]

One of the features I am currently looking at a simple way to self track the HABAXE, i.e. the ability to plot its track without needing a FSK RTTY receiver and a live Internet connection for the Spacenear system.

If you have a Funcube Dongle or even a DVB TV USB receiver these are fairly effective USB\LSB receivers (needed for the FSK RTTY), however they do need fairly powerful PCs to run them, I had no luck with my cheap\light\small Windows 8 Netbook. There is the option of using one of the cheapest multi mode HAM receivers out there, the Yaesu FT817 but those are hardly inexpensive (£600).

So perhaps a simpler, cheaper approach would be worthwhile investigating.

The RFM22B is by design a telemetry transceiver and capable of sending and receiving data packets. The receiver and antenna (see previous post) used with a good low noise amplifier (70cm VLNA by G4DDK) are known to pick up the RFM22 telemetry transmitted at 100mW from around 1000km. At the reduced power of 10mW from a HAB tracker, 200km or so ought to be feasible with the same setup assuming the tracker is high enough to be above the radio horizon. Without the LNA, £55 as a kit, the range would be reduced to ¼ or around 50km. The RFM22B receiver is a low cost build, and whilst it puts the received info out to the serial terminal so you can see it on a PC, it also drives an inexpensive Digole LCD, allowing a small compact battery powered unit to be built.

Note that if the tracker is below the radio horizon then your not going to hear it, no matter how effective your transmission protocol is.

The RFM22B portable receiver can translate the telemetry received into NMEA GPGGA and GPRMC sentences and send them out to the program download port as serial data. There are PC applications, such as Memory Map, which will accept this input and record the track on a screen map, you get a live view of where the tracker is, its altitude, distance and direction from home, with no need for an Internet connection.

To test this setup I put HABAXE with its own battery on the dashboard and had the telemetry receiver and Netbook on the passenger seat. The receiver was connected to the Netbook with a AXE027 lead. The PC was receiving the position information over a wireless link from HABAXE, even though the distance was only a metre or so. I took it all for a few hour long drives and the track of HABAXE was accurately recorded, within 10M or so, as a track over the map on the Netbook screen, no spurious position reports were seen.

I am hoping to do a test launch when I am away for a week ‘Up North’ watching the Tour de Yorkshire.

 

[srnet]

The old version of Memory Map (2004) I have works well even on my el-Cheapo Windows 8 Netbook. Although the interface to the GPS (telemetry reciever) needs a keep alive character sent at least every 5 seconds or the GPS connection times out. You can also get a window which displays the time, position, altitude, speed and track of the remote tracker (HAB).

The latest version of Memory Map does not work at all really, the GPS connection times out, you get Visual C++ errors etc. Other HABers have reported similar problems. A product to avoid I think.

There is a APRS tracker, YAAC, which will do the job. You dont have to use the APRS stuff, but it will highlight the position of your GPS (the HAB in this case) on a map display. It can used downloaded precompiled map tiles (free) or convert maps from the openstreetmap project (free). The map display is not as good as the detailed and pretty colour OS maps, but good enough for the purpose, and free.

 

[srnet]

After a week of driving back and fore to work (40 miles) with my tracker and wireless link working, its clear the self tracking using the RFM telemetry from HABAXE is going to be a useful option.

The receiver, that plugs into the PC and pretends to be a GPS, could be either the portable unit I built (see previous pictures) or another tracker acting as the receiver.

 

[srnet]

One quirk I have spotted with the Ublox GPS, is that the speed from the GPRMC sentance is not correct.

My portable telemetry receiver was showing the wrong speed, I was driving at a constant 96kmph (60mph), but the receiver display was only showing 50kmph or so. There is quite a few steps to get the data from the GPS and over a wireless link to the LCD display so I initially thought a program error.

But checking the log produced by the GPS collector showed that the speed field in the GPRMC sentence has the wrong data in it, there must be some form of calculation error in the GPS.

Interestingly both Memory Map and YAAC, display the correct speed, so they may be calculating it from the previous GPS data.

 

[srnet]

So far so good.

It all appears to be working, data telemetry, FSK RTTY, AFSK RTTY, Slow Morse beacon and command uplink ability.

The output format in RTTY is;

$$HABAXE1,sequence,time,lat,long,alt,speed,track,GPSruntime,Fchanges,batterymV,temperature,flags*CHECKSUM

The code and stuff can be found here;

https://www.dropbox.com/sh/ddtjsxkr2kcph2g/AAAEiojS9xv_mSmcCUlns38Ca

Can someone say if the link is not working.

The program is 3 slots, transmitter in slot 0, GPS collector and parser in slot 1, the measurements, battery, temperature, pressure in slot 2.

I have 5 spare PCBs, which anyone can have for free.

 

[sages]

Quick check of dropbox link appears to be ok. Checked schematic download.

 

[srnet]

Thanks.

I have tried to use Github for this sort of thing, but its seems to be a lot to learn for something that is so simple.

I have a Dropbox folder, and all I need do to update the on-line store is copy the latest software version into the dropbox folder, simple.

 

[srnet]

I have not yet had a chance to flight test HABAXE yet, the board and code was working well enough, but I ran out of time to have everything else ready and well tested on time for my trip up North.

I eventually realised why the speed output was wrong, it was a case of RTFM, the GPRMC sentance puts out the speed in knots. For now I ran a conversion of the field from knots to kmph, but eventually I will likely change the software so that it reads the GPVTG sentance where the speed is already in kmph.

 

[srnet]

I had a chance to try the AA Lithium (1.5V) to 3V boost converter. Microchip do a chip specific for the purpose, the MCP1640.

The efficiency of the converter is around 75%, approx 185mA in for 68mA at 3.0V.

With the GPS all the time, an AA Lithium wieghing 14.7g would last about 17hours, a 15g 600mah Lipo lasting about 8.2hours.

However, the boost converter generates a fair bit of high frequency noise, enough to stop the GPS aquiring a fix. Granted the antenna is only one of the little ceramic chips (weak signal) but its not a good start.

With a good signal (and a quiet supply) the GPS can be powered down and will reaquire fix in 5 - 8 seconds, giving considerable power savings. So even if the boost converter can be made to work for a tracker (others have done so) the GPS is likley not operating at optimum, this could lead to higher power consumption overal.

 

[srnet]

It occurred to me that I could feed the output of the MCP1640 boost converter at 3.2V or so into the HABAXEs, MCP1700 3.0V regulator, this regulator has a very low dropout in the range of 50-70mV that the current HABAXE circuit uses.

This does remove most of the higher frequency noise, but the low frequency (almost DC) regulation of the MCP1640 booster is dreadful, I get dips from 3.2V to as low as 2.35V as the GPS and transmitter switch on\off, current with both on is about 100mA.

Good layout (the boost circuit is on a breadboard at the moment) should help to remove the high frequency stuff, but wont help the very poor DC regulation.

 

[srnet]

I have been playing with the Ublox Ucentre configuration utility, it allows you to test the various configuration options without having to re-program the PICAXE all the time.

You need an AXE027 programmed to non-invert mode, or you could add one of those mini tri state inversting buffers to allow a standard AXE027 to be used.

I was power saving by switching the GPS on\off via a MOSFET.

It looks like switching the power is not necessary, by sending a suitably formatted CFG-PM2 message, you can get the GPS to power up, wait for a re-aquistion of a fix, and power down again. Its taking typically 3-4 seconds of power up time to re-aquire after being off for 30 seconds.

If the battery went really low, say only 100maH of 600maH left (15g battery), you could put the tracker to sleep for much longer periods. With no special design effort the sleep current of HABAXE (with GPS in sleep mode) is about 200uA. You could wake up every 5 minutes say, it would then take around 20 seconds at an average of 50ma to get a GPS fix and transmit it. The remaining 100maH of battery would then last about 30 hours.

The newer Ublox 7 GPS is supposed to be even more power efficient, I have one here, so we shall see.

 

[srnet]

There are two test programs on the dropbox;

HABAXE V2 Test GPS Collector OnOff Power.bas

HABAXE V2 Test GPS Collector Cyclic Mode.bas

During the initial aquistion the Ublox6 takes about 65mA, which is quiet a lot for a small and light tracker, the two programes demonstrate two different approaches to power saving on the GPS (Ublox Neo 6M).

Both programs initially power up, check the GPGGA sentance for a fix (can take up to two minutes from cold), then check the GPRMC sentance, then print out the GPGGA and GPRMC that are stored in scratch pad and finally go to sleep for a minute, wake up and repeat.

The first program powers the GPS down after reading a fix, the GPS spends most of the minute turned off and the whole HABAXE circuit then only takes about 350uA. Normally you need a battery on the Vback pin to allow for a hot start on power up, but in fact all thats needed is a voltage, so a simple resister to the main VDD supply (3.0V) will do. After the sleep period, the GPS is woken up and it re-aquires a fix within about 5-10 seconds, a hot start. So in on\off mode you need about 65mA of current for up to 10 seconds every minute, so an average of 5mA to 11mA.

The second program puts the GPS into cyclic power save mode, and the internal firmware of the GPS then manages switching off the various parts so that once a fix is aquired, it only need wake up most of the GPS internals every few seconds. In this cyclic mode while position fixes are updated less often, its enough for a balloon tracker and the average power consumption drops to around 12mA. However, in tests the cylic mode does not always have good enough signals to go into 12mA average mode and the current howers around the 44mA mark.

HABAXE has the componets to remove the power from the GPS via a P Channel MOSFET, but the power down funtion of the Ublox is effective enough that these componets are not needed.

I have tried a Ublox 7, this is supposed to be much lower power and indeed the power consumption during first aquisition indeed low, 25-27mA. However the module I have (from UKHAB supplies) does not have as much signal gain as the Ublox6 I built into HABAXE, and the Ublox7 takes foreever to aquire a fix, 15 minutes in one case. Thus it ends up using far more power than the supposedly less advanced Ublox6.

 

[srnet]

Cut down - balloon release

Just tested the mod to allow a remote cut down (balloon release) of HABAXE.

Remotely operated cut downs don’t seem popular in the UK, which is odd considering the obvious safety benefit of being able to terminate a flight if the balloon drifts where it should not.
One reason seems to be a belief that the transmission of a cut down signal is not allowed, even for a radio amateur. Ofcom seem ambivalent on the issue, and for it to be illegal the receiver on the airborne balloon would need to be deemed part of the ‘amateur radio station’. This seems completely untenable as no license is required to own or use an amateur radio receiver in the first place, so how can a receiver also be considered part of an ‘amateur radio station’ ?

However, whilst the use of an amateur radio license would be needed to if you wanted to use a high power amplifier to send a cut down signal say 1000km (needs about 5W ERP), the RFM22 can be used on its own over shorter distances.

Transmissions of 10mW are licence exempt, and this would have a range of about 15km, ground station to balloon. RC control in the 458Mhz band at 100mW is allowed in the UK, and this would have a range of about 40km.

The RFM22 can easily switch between transmitting on one frequency, license exempt at 434mhz say, but then listen on an amateur radio frequency or the RC control frequency of 458Mhz. Similarly the ground station can easily switch between downlink and uplink frequencies.

Implementing a cut down is actually very simple with a small MOSFET and a Lipo.

You can get ready made nichrome wires, a short length of nichrome with two bits of copper wire welded on, these are ideal for melting a bit of nylon cord.
I measured the current it took to melt a bit of dyneema, its stronger than nylon and has a lower melting point. The cord cut within 10 seconds at a current of 800mA.
I next measured the short circuit current of a small 70mah Lipo weighing 2.2g, it was 6A with the protection circuit removed, that ought to be plenty.
A DMP1045 SOT23 MOSFET will handle 5.5A, has a rated forward resistance of 31mR, and a gate source threshold voltage of 0.55V.

So all we need to do is arrange for the ground station telemetry receiver (see picture) to transmit a command packet at the appropriate time. In the case of HABAXE it goes into listen mode just after the FSK RTTY and telemetry packets are transmitted, at this time just press the button on the ground station receiver, and the cut down packet is sent.
When the cut down command is received, the MOSFET is turned on, the nichrome wire goes red hot and the dyneema cord breaks within about half a second. See the arrangement in the picture.