3700RE: [V4Protocol] H4 Protocol spec for FEC and ARQ posted to V4Protocol files section.
- Nov 27, 2013
There are two things that are interesting.
1) The ¼ at the end of the ARQ ID is due to the CRC byte which actually should be suppressed since it is preceded by an End of Transmission…I’ll have to check that out. Of course in ARQ mode everything will be hidden unless it passes the CRC check sum.
2) The scalloping on your decode quality graph indicates possible large error in your sample rate. On the H4 TNC (after it has been running for several minutes) click Help and note the SR number at the bottom of the drop down. It should be fairly close ( +/12 or better) to 12000. If it is far off your sound card has some significant error. It will still decode but can’t be fully compensated. Let me know what you read for the SR value….(be sure and let it run…the longer it runs the more accurate the reading)
3) The receive level looks low. With the receiver AGC on (medium to fast) it should be at least 50% of full scale. It looks like it is only half way on the blue scale which means you are using something like 8-9 bits of your sound cards A/D. That hurts the decoding accuracy and sensitivity. Shoot for at least mid scale or better and “in the green”). You set this with:
a. The radio aux or speaker/phone output level (sometimes this is adjustable)
b. The pot and/or jumpers in the sound card interface. (e.g. the SignaLink has both an internal jumper and a RX pot.)
c. The windows mixer record level (if the sound card driver uses the windows Mixer. ) You can check this with Start, Control panel, Sounds and selecting the card and record level that you are using for the radio.
Thanks for the feedback….It shows the ARQ ID is working but that ¼ should be suppressed. I’ll find that this afternoon.
Rick, here's a screen shot of 2 of your beacons. The stuff before your beacon is just noise that got through. I was wondering why the start of beacon doesn't start on a new line. Also, what is the 1/4 at the end of the beacon.
73, Ron ny3j
On 11/27/2013 6:04 AM, Rick Muething wrote:
Many of us have heard the famous Abe Lincoln quote:
“Give me 6 hours to chop down a tree and I will spend the first 4 sharpening the axe.”
The same still holds pretty well for developing a protocol!
I have made good progress on the H4 ARQ mode …initially mostly in the protocol spec. I have uploaded this to the files section (pdf) for anyone interested or having trouble getting to sleep. I have found that time spent “sharpening the spec” is well spent and makes the coding faster and with fewer iterations.
I am running special (I don’t want to post these yet) Chat and H4FSK TNC test versions here that is sending both an FEC beacon and a new ARQ ID frame. You should be able to see a clean (no funny characters caused by the CRC check) ARQ ID after my FEC beacon. It is on 10123.0 USB dial and sends the short ARQ ID frame (“ARQ ID < KN6KB”) a few seconds after the FEC beacon. Of course monitoring with FEC will not provide error checking or correction but it should be visible. I have gone to some effort to insure that monitoring of ARQ sessions can be done in both ARQ and FEC modes with clean printouts. This is all described in the “very interesting” spec.
I suspect it will be at least a couple of weeks before a fully functions (with a few bugs of course!) ARQ version is ready for testing. This includes the provisions (as you can see in the spec) for a second Reed-Solomon layer FEC on top of the Hamming encoding. This is used on the Robust Text and BINARY frame types…it reduces the frame payload some but should improve the net throughput (after repeats) in poor conditions.
I’ll leave the beacon running today. I’m interested in how the ARQ ID frame “prints”.
Have a good Thanksgiving…
- << Previous post in topic Next post in topic >>