Bugs, bugs, bugs

What a weekend. So, the box went live on Thursday evening, and by Friday it was obvious there were problems.

In no particular order, the problems I found and fixed:

1) Local repeat. The biggest pain. Satoshi's firmware requires a constant supply of packets to transmit - if they are lost, then PTT is switched off. Now, say you are a mobile user or a marginal signal - then DV frames will be lost. I was simply reading in frames off-air, and echoing straight back out - a BIG mistake. As soon as I lost a frame, PTT went off. The solution - a dual-leaky buffer system. Collect incoming frames and pre-fill the buffer on Satoshi's board. When the buffer reports it is full, then switch the PTT on and keep topping up the queue. So, leaky bucket #2 is in the Satoshi board, leaky bucket #1 in my code. I also watch for the spacing between incoming frames - if I see lost frames then I in-fill with Null Voice frames. This was a major re-write of the code.

2) FM lock-up. I was able to stall the repeater by forcing the squelch to open - it sat and waited for a DV Header which never happened. So I've implemented a timer and COS check.

3) Lock up on RPT1/RPT2 set. Still work-in-progress. Essentially, anyone that had RPT1 set incorrectly (or not set at all) was also causing the repeater to lock-up. This was because I had changed the DV Header handling as above and the result was coming back as a valid Header, but not enough data. I've worked around it for the time being - what should happen (I think) is that the repeater should allow you to work locally, but at the end of your transmission should respond with "RPT GB7MH B" that auto-fills in some rigs. I'm going to test this later on a real Icom system to see what responses come back.

4) Tail echo. Because of the way that I pre-fill the playout buffer, then raise PTT, when the transmission finishes, there is audio left in the buffer. I have two choices - 1, cut the transmission off early or 2, playout the remaining buffer to the end. I do 2 at the moment, but this leads to an overhang of about 1.5 seconds. In other words, you hear the end of your own transmission after you de-key. Now, in some ways, this is good - you can be sure that you've hit the repeater, but in other ways it is bad - I hate hearing my own voice. The solution is to pre-fill the playout buffer quicker, but I'm using low-speed USB, so I'm limited to 8-bits per transaction which takes around 1.7ms. Once I've sorted out the user responses (UR ?, RPT ? etc) then I'll think about other solutions.