I’d like to draw attention to an issue I’ve experienced building the latest VAYU-NTX v1.04 board. I had previously built one that suffered from the same issue but I ended up very frustrated and this probably contributed to my having a break from Electronics/HAB for a while. Eventually, I stripped the old non-working board for parts (they’re expensive!) so at the time, I never found out what the issue was. I assumed that it was one of the components and I kept them separate from ‘stock’.

Fast forward to last Sunday, June 29th 2014. I was eager to build a payload to update my cobbled together firmware. I had purchased a cheap toaster oven from Currys which I thought would be good for reflow purposes and I wanted to try it out. I had done a few test runs with sacrificial boards to ascertain the time required for the solder paste I had obtained on eBay. It worked well, especially since the solder paste’s profile is almost straight up and down with little discernible soak period.

I carefully laid the components out on the new board after carefully applying the solder paste via the stencil I had made when the boards were fabricated. I placed the populated board carefully in the oven and hand timed the heating, using a further sacrificial board with some blobs of solder paste to confirm the time. I saw the solder melt at around 2:35 and left the board under heat for a further 20secs. I then switched off the oven, very carefully opened the door (after making sure there was adequate ventilation!) and let the board cool down. Much to my delight, the components were soldered perfectly. I finished the board by adding the NTX2 module from the previous board. I was pretty sure this wasn’t the culprit of the last board’s issue since I’d received an RF signal from it.

VAYU-NTX v1.04 Newly Built

Two things to notice; the awfully soldered power header on the right. It works. I’ll replace it at some point. And the two test connections for +VCC and GND on the left that I removed, more on that later.

The time had come to load the firmware so I started up the Arduino IDE and tried to bootload the board. I found that the custom entries in boards.txt I had previously had now gone. When I was building the v1.03 board, I had help from Chris Stubbs who assisted me by defining a custom entry in the boards.txt file in the Arduino software. This enabled the application to download a bootloader into my newly built VAYU-NTXs. I must have overwritten the old Arduino software with a new version, loosing the custom entries. Well, I thought, all I really need to do is set the fuses (Fresh ATMEGA328s are set to run on their internal r/c oscillator). I opened Atmel Studio 6 and set the fuses to: Low 0xFF High 0xDA Extended 0x05. I went back to the Arduino IDE, compiled and then uploaded the firmware; This is where the issue begins.

When powered up, I found the familiar tone at around 434.445MHz. This indicated that the NTX2 was sending a signal. With the current firmware, the signal stays here as a constant tone and then jumps up in frequency once a satellite lock is obtained and starts sending the RTTY Telemetry signal. I waited for 25mins before assuming it wouldn’t GPS lock. This was identical to the issue that the previous board had suffered. At least, I thought, it’s probably not the hardware. The only two components I used from the previous board were the NTXb module and the GPS antenna, all the others were new.

I begun troubleshooting by programming the status LEDs to blink. This proved the ATMEGA238 was alive and working fine. The NTX2b I’d already decided was OK since the RF signal was nice and strong. I tested the GPS module by connecting the TXD output from the test point into a logic analyser and that showed serial GPS data as expected. Was it the layout? The last working board was VAYU-NTX v1.03 which didn’t have the +VCC and GND test points near the GPS antenna. Could these be affecting the GPS reception? I removed them on both sides along with the through hole plating (sorry Mitch!) but that didn’t fix it either. As you can probably guess, I was pretty confused by that point.

After a break, I remembered a phrase on Anthony Stirk’s website “If you’re ever unsure if your radio is working you should step back to this extremely simple code to check the basic operation.”  So I heeded that advice and loaded the simple RTTY code (from Pt. II). I was amazed to find it produced a signal but it was remarkably slow. Half speed in fact. DlFldigi (The software used to receive telemetry) couldn’t resolve it at all. Why was this? I had set the fuses correctly. In fact, at that point I double checked them to be sure. Puzzling. Since I couldn’t get DlFldigi to resolve the signal with it’s settings, I dived into the firmware and fixed it from inside. I halved the transmission delay in the code. But, no, this still didn’t fix it. I searched for other timing dependent lines in the code. OF COURSE! The GPS serial speed of 9600 baud. I doubled this to 19200 baud and finally, it worked!

So, after mulling this over, I realised that, for whatever reason, the ATMEGA328 was running effectively at double the speed it should be. It was being treated like an Arduino UNO. Even though I had set the fuses for 3-8MHz external crystal operation. I remembered back to how I initialised the working boards and each of them did have the bootloader installed before overwriting it with the firmware via ISCP. It made no sense to me to do this but after chatting with some of my friends over IRC and via e-mail, I went ahead. Firstly I had to re-create the custom boards.txt entry (Thanks again to Chris Stubbs for his help with this). Chris gave me a copy of his version which I customised further to work with VAYU-NTX. This is the text I ended up with:

##############################################################

vayu.name=VAYU-NTX (3.3V, 8 MHz) w/ ATmega328
vayu.upload.tool=avrdude
vayu.upload.protocol=arduino
vayu.upload.maximum_size=30720
vayu.upload.speed=57600

vayu.bootloader.tool=avrdude
vayu.bootloader.low_fuses=0xFF
vayu.bootloader.high_fuses=0xDA
vayu.bootloader.extended_fuses=0×05
vayu.bootloader.file=atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex
vayu.bootloader.unlock_bits=0x3F
vayu.bootloader.lock_bits=0x0F

vayu.build.mcu=atmega328p
vayu.build.f_cpu=8000000L
vayu.build.board=AVR_UNO
vayu.build.core=arduino
vayu.build.variant=eightanaloginputs

##############################################################

I then proceeded to upload the bootloader after erasing the chip fully in AVR Studio, just to be sure I started with a clean slate. I then compiled and uploaded the old unedited firmware – EUREKA! After 4mins or so, the board locked and started sending telemetry, just as the older boards had done, and with no false settings needed in the code.

OK What’s going on. How is it that you can set the AVR Fuses to run at a particular frequency and still get an anomalous output? Well, I believe it’s all down to the “vayu.build.f_cpu=8000000L” line in the boards.txt entry. I think that this defines the speed for the Arduino software and all the speeds are referenced from this. Of course, that means that if you set serial to be say at 9600 baud, the Arduino IDE software will effectively set 19200 if you’ve set the board incorrectly (an Arduino UNO running at 16MHz for instance).

OK So I believe the mystery is solved. To program the VAYU-NTX boards successfully, you have to have a custom entry in the boards.txt to make sure the Arduino IDE software sets the correct timing. I have since documented this on the VAYU-NTX page so that anyone building one doesn’t suffer the same pitfall.

Let me know if you have experienced a similar problem or indeed, attempted to build a VAYU-NTX – e-mail to steve(at)projecthab(dot)co(dot)uk

I’d also like to take this opportunity to thank all the guys who helped me work through this problem and led me to the final conclusion. Charlie Robson, David Prentice, Matthew Beckett, Chris Stubbs, Andrew Garrett, Anthony Stirk & Dave Akerman. All of whom contributed somehow.