I was debugging problems with the code for 16 hours yesterday. Right after my optimistic log post I noticed a few problems with the code and fortunately after staying up till 4 AM figuring them out I can be optimistic again. This post is just going to be about last nights debugging session.

The most critical problem I encountered was that no demodulators besides my own would demodulate the signal from my modulation code. It baffled me for about 3 hours. I played with the signal in Audacity trying to figure out what was different between my output and the output of another piece of APRS software. In this case APRS Droid. I adjusted the timing, tried adding pre-emphasis, compared both waveforms in spectrogram mode. It was when I was trying to add more pre/post ambles to the signal that I noticed what the problem actually was. As you can see in the image below my signal (Top) has an extra bit inserted.

An odd problem for sure. But at least I know why my decoder could still make it out. When it gets a postamble it chops off any extra bits and returns what it has so far. Apparently other decoders aren't so flexible or forgiving. Ultimately I needed to subtract 1 to the if statement that changes the modulator stage from data to postambles.

// old
if(current_bit >= self.len * 8)
    AFSK_Modulator_advance_stage();

// new
if(current_bit >= self.len * 8 - 1){
    AFSK_Modulator_change_frequency();
    AFSK_Modulator_advance_stage();
}

I'm not sure why I needed to do an additional frequency change but that adjustment made the modulator spit out the right waveform. The timing was also slightly off so I changed the divider of the DAC clock down by one and everything I sent out was clearly decoded. MixW 2.20f showed it at 1203 baud, so slightly off but it seems its within tolerance.

The next bug was also rather troublesome but it was primarily a poorly written test that caused most of the delay. I programmed it to use base64 for sending the message data over the UART to and from the PIC. This way the stream can still be managed by new lines and everything is printable. The command I was using to send the packets was:

TX="gqCIpGJk4JaIYK6OrGqukoiKYkBjA/A9MzkwMC4wME4vMTA0MDAuMDBXJCBodHRwOi8vYXByc2Ryb2lkLm9yZy84yQ=="

It's the test data I got from APRSDroid to figure out what was wrong with the modulator. My first send naturally was not decoded because of bugs in the base64 decoder. The hex my demodulator spit out didn't match what was expected. Turned out to be a simple case of using a back slash where I should have had a forward slash as well as adding the wrong number in one of the if statements to decide what value a character should have. These problems where both fixed in a few minutes.

What ended up really getting me was a mistake I made in writing a unit test for the base64 de/encoder. I used python to convert the base64 to its binary equivalent and then copied that to the C unit test into a const array.

"gqCkpkBA4paIYK6OrGfwA1Rlc3Rpbmc67w=="

'\x82\xa0\xa4\xa6@@\xe2\x96\x88`\xae\x8e\xacg\xf0\x03Testing:\xef'

Unfortunately when manual converting the \x to 0x I also inadvertently deleted the ' and the g. The 2 printable characters mixed in with the hex. Stupidly I analyzed my code for about an hour trying to figure out how the test could be failing and I was missing 2 bytes in my decoder output. Eventually I realized the mistake.

So I got bitten by unit testing twice yesterday. Because my unit tests for my modulator showed it working because my demodulator is more flexible than others. And by mistyping the expected result into the base64 unit test.

Moral of the story is double check your unit tests.

As for the current status of the project. I was hopping to get the AMS002 modules today but still waiting on those from Mouser. The prototype is tested receiving from and getting into the APRS network successfully. The code has been reorganised a bit and I feel its easier to follow and maintain. The serial command interface for the PIC has been improved using standard commands like TX with base64 encoded data to send. It sends RX="base64data" for what it receives. I implemented PPT function via a 2.2k resistor to ground from the mic line sunk with a NPN and its fully functional. I think I will see if the any of the PIC pin's can sink enough current to save me the extra component on the board.

Looking good overall. I expect to have fully functional breadboard prototype by end of next week with all the components the final version will have. (Battery, Charge Circuit, BluetoothLE). Then I expect it will be about 2 weeks to get PCBs for the smaller prototype and a week for building and testing. Looks like it will be about 5 weeks till I have a usable final prototype!

If you want to monitor any progress I'm making with the unit you can track my callsign KD0WGV-5 on aprs.fi to see what I've been broadcasting. I'll include little messages about how things are going in my test packets.