Loading ...
Sorry, an error occurred while loading the content.

21404RE: [aprsisce] Beta testing Dire Wolf modem

Expand Messages
  • Steve Daniels
    Dec 18, 2012
    • 0 Attachment

      Lynn has a copy and I hope he might do a bit on integration between the two, or talk to john about it. Either by changing the conf file or maybe building it into APRSIS if John allows it.

       

      Steve Daniels

      Amateur Radio Callsign G6UIM

      Torbay Freecycle  Owner

      http://uk.groups.yahoo.com/group/torbay_freecycle

      APRSISCE/32 Beta tester and WIKI editor http://aprsisce.wikidot.com

       


      From: aprsisce@yahoogroups.com [mailto: aprsisce@yahoogroups.com ] On Behalf Of Colin XSD
      Sent: 18 December 2012 07:38
      To: aprsisce@yahoogroups.com
      Subject: Re: [aprsisce] Beta testing Dire Wolf modem

       

       

      Thanks Steve,

      I have it working now and first impressions are: 'it appears to be very good'.
      My only complaint is having to edit the .conf file to change which SoundCard it uses. My Laptop has 2 built in (internal & External) and I have a Bluetooth Headset along with the USB Dongle I use for APRS, the trouble is that it appears to be a Lottery as to what number Windows7 assigns to which device when DireWolf starts up. So far every time I start DireWolf they are in a different order but edit the .conf & fire it up again and it works.
      I did have similar problems with the UZ7HO SoundModem but with that it was only a problem at Windows startup, once set at the start of the day it was OK from then on.


      73,
      Colin
      M0XSD.

      On 17/12/2012 23:19, Steve Daniels wrote:

       

      Well have been testing Dire Wolf sound modem version 0.6 beta and I must say I am impressed.

      Have tested VHF land and also via ISS going to test HF now.

      It’s fully configurable for modem tones and baud rate and you can setup 2 channels

      The author has given me permission to let people have the beta version of 0.6 for testing

       

      Dire Wolf also has the ability to run as a digipeater.

      Anyone wanting to try email me off group and I will send you a copy. It will run on Windows and Linux but I only have the latest Beta in a Windows Version, I do have the source code for an earlier version

       

      Steve Daniels

      Amateur Radio Callsign G6UIM

      Torbay Freecycle  Owner

      http://uk.groups.yahoo.com/group/torbay_freecycle

      APRSISCE/32 Beta tester and WIKI editor http://aprsisce.wikidot.com

       


      From: aprsisce@yahoogroups.com [mailto:aprsisce@yahoogroups.com ] On Behalf Of Steve Daniels
      Sent: 12 December 2012 22:46
      To: aprsisce@yahoogroups.com
      Subject: [aprsisce] Beta testing Dire Wolf modem

       

       

      Beta testing a new version of Dire Wolf sound modem that tries to correct any bit errors rather than throwing the whole thing out. Available in Windows and Linux versions.

      It can connect in 2 modes to APRSIS32 AGW or IPKISS. IPKISS looks to APRSIS32 like a KISS modem only the connection is via an IP port. I needed a KISS modem on a com port and asked John if he could add it, so I could use an IP to com port emulater to drive a different program.

       

      Here Is the section of the manual that deals with the error correction, there is more info in the manual.

       

      There is an old proverb, “One bad apple spoils the barrel,” which applies to AX.25 frames used for APRS and traditional packet radio. Each frame contains a 16 bit frame check sequence (FCS) used for error detection. If any one bit is corrupted along the way, the FCS is wrong and the entire frame is discarded.

      The Osmond Brothers offered the advice, “Give it one more try before you give up…” That can also apply to AX.25 frames. From my observations, single bit errors are fairly common. Why not give it one more try before giving up?

      My original attempt at receiving APRS signals performed the HDLC decoding real time on the bits from the AFSK demodulator. If the FCS was wrong, the frame was discarded. The original bit stream was gone. No second chances.

      In version 0.6, the HDLC decoder was rearranged to operate in two different phases. The first phase only looked for the special 01111110 “flag” patterns surrounding the frames. The raw received data was stored in an array of bits without undoing the “bit stuffing” at this time. This stream of bits was then processed in the second phase. This provides an opportunity to give it another try if it didn’t go well the first time.

      For single bit errors, we can try to invert each of the bits – one at a time! – and recompute the FCS. My experimentation found this recovered a lot of packets that would normally be discarded. Experimental results are summarized in a table later.

      What about two or three adjacent bits getting clobbered along the way? If something is good, then more must be better. Right? The next experiment was to try modifying groups of two or three adjacent bits.

      Why stop at modifying only adjacent bits? What about two non-adjacent (or “separated”) single bit errors? This also allowed a fair number of additional frames to be decoded but at a much larger cost. The processing time is proportional to the square of the number of bits so it climbs rapidly with larger packets. This often takes several seconds rather than the couple milliseconds for all the others.

      There is one little problem with flipping various bits trying to find a valid FCS. We get a lot of false positives on the FCS check and end up with bogus data. Callsigns contain punctuation characters. The information part has unprintable characters.

      The 16 bit FCS has 65,536 different possible values. Even if totally random data goes into the checking process, you will end up with a valid FCS one out of every 65,536 times. When you try hundreds or even thousands of bit flipping combinations and process lots of packets, a fair number will just happen to get past the FCS check and produce bad data.

      My solution was to run the results through an additional sanity check. A valid AX.25 frame will have:

       An address part that is a· multiple of 7 bits.

       Between 2 and 10· addresses.

       Only upper case letters,· digits, and space in the addresses.

       For APRS, the information part has only printable ASCII· characters or these:

      o 0x0a line feed

      o 0x0d carriage return

      o 0x1c used by MIC-E

      o 0x1d used by MIC-E

      o 0x1e used by MIC-E

      o 0x1f used by MIC-E

      o 0x7f used by MIC-E

      o 0x80 seen in "{UIV32N}<0x0d><0x9f><0x80>"

      o 0x9f seen in "{UIV32N}<0x0d><0x9f><0x80>"

      o 0xb0 degree symbol, ISO Latin1

       

      (Note: UTF-8 uses two byte sequence 0xc2 0xb0.)

      o 0xbe invalid MIC-E encoding.

      o 0xf8 degree symbol, Microsoft code page 437

      After applying this extra step of validity checking, no bad data was ever observed for the single bit fixing case. In very large sample sizes, there were a few cases of bad data getting thru when flipping more than one bit.

       

      Steve Daniels

      Amateur Radio Callsign G6UIM

      Torbay Freecycle  Owner

      http://uk.groups.yahoo.com/group/torbay_freecycle

      APRSISCE/32 Beta tester and WIKI editor http://aprsisce.wikidot.com

       

       

       

    • Show all 20 messages in this topic