Progress

I initially used a 3amp LM7805 regulator to provide the 5 volts to the Beaglebone Black (BBB). This regulator will not work unless the input voltage is at-least 6.5 volts. So a 6 volt battery is not much use. So the original configuration had 2 x 6 volt batteries (in series) producing 12 volts which meant that the regulator was generating a LOT of heat. Very wasteful and not good if we have to go out to places where it is very hot and the regulator gets too hot.

I discovered that the is a regulator that has lower voltage offsets, about 0.5 volts. LM2940CT-5. When the input voltage drops below 5.5 volts, the output voltage is INPUT VOLTAGE – 0.5V. This device can only supply 1amp. I measured the current draw by the BBB and discovered that it was only about 60 mA! Of course, there could be fluctuations that my cheap meter can’t pick up, but obviously 3A is probably overkill. So I switched the LM7805 with the LM2940Ct-5 and it functions very well, off just one 6 volt battery. I’ll continue to do tests to see how long the groundstation works for off one battery, but I expect it to be pretty long.

This means that the groundstation should be more reliable and will weigh less which will be good for when we track the High Altitude Balloon.

The cut-down mechanism is an extremely important component of the high altitude balloon. Getting a reliable cutdown mechanism is something that was considered difficult. Initial thoughts were to have some external ‘sleeve’ that would wrap around the balloon throat, using a rubber band, or string, velcro or some other material to keep it mated to the balloon. It was however decided that a piece of PCB tube inserted into the balloon to provide a means of attaching the payload could be modified to provide a way to bring a Nichrome wire in touch with the balloon.

The only issue I can see is tying of the bolloon end to stop the Helium gas from escaping. The wires _may_ lead to gaps being present. However if we have sufficient cable ties, each tied up sufficiently, and twist the balloon end around the wires, we should be able to stop any significant amount of gas from leaking.

Take a look at some of the pictures below.

 

Initial tests show that 6 volts is more then adequate to get the nichrome wire red-hot in a few milliseconds. Enough to heat and burst the balloon.

Current flowing through the wires was measured at about 3.5amps.

 

I’ve realised the that the current GPS module only goes up to about 18km. This is not high enough. So I discovered a module that can go up 50km. This module is different from the current one because it doesn’t come with an antenna built-in (on top of it) and it is definitely not a module you can easily get up and running.

The module also needed some TTL converters to convert 3.3v to 5 volt and the 5 volt to 3.3volts. This all takes up a lot of realestate so it became apparent that we need to mount the new GPS module on its own in the PolyCarbonate box, away from the Arduino (where the old one was installed).

Below is a picture of HAB electronics box with new GPS module.

The GPS module is mounted about 1cm above the PCB below it and below Serial Voltage level converter. The board requires 5 v, 3.3v, ground RX and TX.

The antenna is attached to the top of the Arduindo GPS shield using double sided tape. I actually had a problem with the antenna shorting out wires on the Arduino initially. All was okay.

I’ve devised my own firmware for the RFD900 with changes I shall not divulge here. Fortunately the changes have been effective. I’ve been able to download an image 4.5km away in 8 minutes. The link was substantially more stable. It was extremely pleasing to start to see some success after such a very dis-satisfying start.

There are many enhancements that I still wish to make to make use of the hardware/software easier for myself, in terms of ease of use and in terms of getting more feedback, so I know how ‘well’ it is performing.

The project has stalled some what as I test and become accustomed with the new RFD900 modems. Many problems have been discovered during the testing of these modems.

1. There seems to be issues at low bauds with TX (I want to use low baud rates so I have increased sensitivity

2. I’ve been getting RX, essentially corruptions in the incoming packets…losing packets.

3. I’ve found that X-Modem transfer of images just dies when it hits some problems.

It became obvious that I needed to look not only at my software, but also that of the radio modems.  I decided that I would stick with the Open Source version of the software (rev 1.X) as I could go in at my leisure and look for issues in the code…and fix them…or atleast get a better understanding.

I managed to alleviate some of the RX issues by disabling USE_TICK_YIELD

I discovered that if I packed only one byte into the TX FIFO of the radio (rather than 4 bytes at a time), I removed my TX errors.

I discovered that the routines that determine how much data we can pack in, did not take into account that with ECC enabled, there are more trailer bytes.

I discovered that if I missed the start of the x-modem packet, the X-modem perl module would not wait for all the ‘bits’ of the failed packet…and so it would time out and end the transmission almost straight away.

In the end I decided to use:-

S0: FORMAT=25
S1: SERIAL_SPEED=57
S2: AIR_SPEED=16
S3: NETID=25
S4: TXPOWER=12
S5: ECC=1
S6: MAVLINK=0
S7: OPPRESEND=0
S8: MIN_FREQ=915000
S9: MAX_FREQ=928000
S10: NUM_CHANNELS=50
S11: DUTY_CYCLE=100
S12: LBT_RSSI=0
S13: MANCHESTER=0
S14: RTSCTS=0


It seems to work well with initial test around the house and up the street. It is also a bit faster then the 8kbits/second.
of course, things might change after I do a bit more testing.
	

I’ve managed to add functionality to the page to display they mobile phones GPS coordinates on the web page on the status page. I’ve also coded the status page to calculate a few interesting numbers.

1. The distance (Across the surface of the earth) from the user’s mobile phone to the HAB

2. The LOS from the users’s mobile phone to the HAB (i.e. we take into account the altitude)

3. The bearing  – (direction from the user’s mobile phone to the HAB).

Obviously, the user needs :-

* Use a mobile phone with GPS

* Have GPS enabled…not the WIFI as a means of locating itself

* Allow sharing of location with the browser

This information will be very important when we need to track the HAB! I’m pretty happy with that!

Progress has been slow in the radio link side of things. Testing of the new RFD-900 modems has been painful for a number of reasons.

1. They chew up a lot of power and go through a lot of batteries and I have a feeling that when the RFD-900 demands a lot of power, the batteries just cannot supply it.

2. There seems to be packet loss, and some very strange things occuring. I’ve been in contact with the supplier regarding this.

3. I SUSPECT there is some interference between the wifi and rfd-900…but there is a lot more work to do there.

So in short, I’m a long way from doing some long range tests and I’m probably going to need to purchase more batteries.

I purchased myself some 18650 batteries from China – 8 in total. For those who are unfamiliar with 1860 batteries, they are 18mm in diameter and 65mm long. They are Lithium Ion batteries with a voltage of 3.7 volts.

These batteries fit in a battery box that fits VERY snugly in the main Electronics box. Alas…on the first test, the batteries failed after 30min of operation. It turned out that one of the batteries died – collapsed. This apparently happens if too much current is drained from these batteries, or they are charged with a charger in a ‘bad’ (over voltage?) way. That is apparently why most 18650 incorporate a circuit protector to stop this from happening. (When they have this circuit protector added…they are typically a few more mm longer).

I suspect I’ll need to invest in more expensive (non-China 18650 batteries).

I am continuing to make improvements to the web interface that we will use to get most recent information on the High Altitude Balloon journey. The latest is a TAB with a Google Map showing where HAB has flown. It has the co-ordinates superimposed on the map. There is one potential issue and this is with the fact the phone needs to be connected to the Internet (to connect to Google) and it needs to also be able to talk to the Beaglebone black – simultaneously. Initial suggestions are that this might be difficult. I will continue to investigate ways of setting routes on the phone. There must be a way.