From nivex at nivex.net Thu Dec 18 10:45:24 2014 From: nivex at nivex.net (Kevin Otte) Date: Thu, 18 Dec 2014 10:45:24 -0500 Subject: [Linux-ham] FSK over FM Message-ID: <5492F694.30208@nivex.net> ...or Why 1200 Baud APRS Is So Finicky. http://www.rowetel.com/blog/?p=3799 -- Kevin From nivex at nivex.net Tue Dec 30 12:44:14 2014 From: nivex at nivex.net (Kevin Otte) Date: Tue, 30 Dec 2014 12:44:14 -0500 Subject: [Linux-ham] Opus over 9600 baud KISS TNC In-Reply-To: <53FA313B.3000505@nivex.net> References: <53FA313B.3000505@nivex.net> Message-ID: <54A2E46E.8090102@nivex.net> I migrated the code from my personal SVN over to GitHub to make interaction easier. I also made some headway trying to do text encoding of codec2. Full rundown with github links: https://groups.google.com/forum/#!topic/digitalvoice/vqJ-HnER2lU On 08/24/2014 02:38 PM, Kevin Otte wrote: > tl;dr: > - Code is at http://www.nivex.net/svn/dvopus/ > - I think I've got some buffering problems. > > So, I had a crazy idea: send low bitrate (I chose 7.2Kbps based on what > other protocols are using for "high bitrate" to leave room for headers, > etc.) Opus data using 9600 baud KISS TNCs. I have a Kenwood TH-D7Ag and > a TM-D700A, both of which have those in it. Piece of cake, right? > > Well, getting the encoding and the KISS framing coded up took some time, > but it was all pretty doable. Piping the output of the transmit program > to the receive program via an mkfifo works just fine (with headphones! > The delay is low enough to create feedback). Hooking it up to the > radios, notsomuch. > > First I tried sending from the D7 to the D700. My ears heard data, but > the D700 never returned any frames. I flipped things around and data > started flowing, but it didn't stay that way for long. > > The transmitter would burst a few frames, then unkey, and start again. > The txdelay is 200ms, so that was killing any real throughput. I imagine > the computer would be more than capable of keeping the buffer full so it > wouldn't have to unkey, so I wonder if I have the other problem. That > is, I'm swamping the buffer in the radio. These things were only ever > designed to send APRS frames, and KISS mode isn't even in the manuals. > Eventually I overran a receive buffer somewhere (probably missed a frame > separator) and tripped a failsafe in the code. > > So, I have a prototype, but it doesn't really work. A partially blinking > "Hello World" LED is still an improvement over a doodle on the back of a > napkin, but this still might not be viable. > > Some ideas for improving matters: > - Increase the bitrate, maybe 8Kbps > - Adjust the frame size. not sure whether to go up or down. Up (60ms) > would reduce the per-frame overhead but increase the latency. This might > help the buffering issue too. > > Anyway, that's what I've been messing around with lately. > > 73 de Kevin N8VNR > _______________________________________________ > Linux-ham mailing list > Linux-ham at trilug.org > http://www.trilug.org/mailman/listinfo/linux-ham > From tadd at mac.com Tue Dec 30 14:45:59 2014 From: tadd at mac.com (Tadd Torborg) Date: Tue, 30 Dec 2014 19:45:59 +0000 (GMT) Subject: [Linux-ham] Opus over 9600 baud KISS TNC In-Reply-To: <54A2E46E.8090102@nivex.net> Message-ID: <92e6e5ee-f201-4654-aa3a-c5e8b70d1fb0@me.com> Kevin, This sounds really hopeful. Are you still working on the idea that latency is not permitted? Or are you allowing latency? I would really like to see this working across G8BPQ nodes. If the system used G8BPQ on both ends, we could use SLIP or twisted pair over-audio and take the radios out of the test. I would come up with test radios and digital hardware if this would help. I could do desktop PCs or Raspberry PIs. I can loan DRSI/Kantronics 9600 baud data radios (2 ends) as well as TNC-PI 1200 baud devices. You and I are almost in network range with the TARPN system. I'm putting up a 3-port node in the next two weeks weather permitting at NC86 x i-40. Tadd / KA2DEW - Raleigh NC http://tarpn.net Terrestrial Amateur Radio Packet Network tadd at mac.com On Dec 30, 2014, at 12:44 PM, Kevin Otte wrote: > I migrated the code from my personal SVN over to GitHub to make > interaction easier. I also made some headway trying to do text encoding > of codec2. Full rundown with github links: > https://groups.google.com/forum/#!topic/digitalvoice/vqJ-HnER2lU > > On 08/24/2014 02:38 PM, Kevin Otte wrote: >> tl;dr: >> - Code is at http://www.nivex.net/svn/dvopus/ >> >> - I think I've got some buffering problems. >> So, I had a crazy idea: send low bitrate (I chose 7.2Kbps based on what >> other protocols are using for "high bitrate" to leave room for headers, >> etc.) Opus data using 9600 baud KISS TNCs. I have a Kenwood TH-D7Ag and >> a TM-D700A, both of which have those in it. Piece of cake, right? >> Well, getting the encoding and the KISS framing coded up took some time, >> but it was all pretty doable. Piping the output of the transmit program >> to the receive program via an mkfifo works just fine (with headphones! >> The delay is low enough to create feedback). Hooking it up to the >> radios, notsomuch. >> First I tried sending from the D7 to the D700. My ears heard data, but >> the D700 never returned any frames. I flipped things around and data >> started flowing, but it didn't stay that way for long. >> The transmitter would burst a few frames, then unkey, and start again. >> The txdelay is 200ms, so that was killing any real throughput. I imagine >> the computer would be more than capable of keeping the buffer full so it >> wouldn't have to unkey, so I wonder if I have the other problem. That >> is, I'm swamping the buffer in the radio. These things were only ever >> designed to send APRS frames, and KISS mode isn't even in the manuals. >> Eventually I overran a receive buffer somewhere (probably missed a frame >> separator) and tripped a failsafe in the code. >> So, I have a prototype, but it doesn't really work. A partially blinking >> "Hello World" LED is still an improvement over a doodle on the back of a >> napkin, but this still might not be viable. >> Some ideas for improving matters: >> - Increase the bitrate, maybe 8Kbps >> - Adjust the frame size. not sure whether to go up or down. Up (60ms) >> would reduce the per-frame overhead but increase the latency. This might >> help the buffering issue too. >> Anyway, that's what I've been messing around with lately. >> 73 de Kevin N8VNR >> _______________________________________________ >> Linux-ham mailing list >> Linux-ham at trilug.org >> >> http://www.trilug.org/mailman/listinfo/linux-ham >> > _______________________________________________ > Linux-ham mailing list > Linux-ham at trilug.org > http://www.trilug.org/mailman/listinfo/linux-ham -------------- next part -------------- An HTML attachment was scrubbed... URL: From nivex at nivex.net Wed Dec 31 12:14:06 2014 From: nivex at nivex.net (Kevin Otte) Date: Wed, 31 Dec 2014 12:14:06 -0500 Subject: [Linux-ham] Opus over 9600 baud KISS TNC In-Reply-To: <92e6e5ee-f201-4654-aa3a-c5e8b70d1fb0@me.com> References: <92e6e5ee-f201-4654-aa3a-c5e8b70d1fb0@me.com> Message-ID: <54A42EDE.9000700@nivex.net> It largely depends on what you want to do. Most of my experiments have centered around real time, point-to-multipoint comms similar to our analog voice systems. With VoIP systems you use UDP because the occasional dropped frame isn't going to go noticed. Once you add in the reliability/retransmission layer, you not only effectively half your available rate, but your end-to-end latency becomes wildly variable with network congestion. Not good for realtime. If we ignore the need for realtime and just want to move the voice across a NET/ROM network, you are basically looking at a store-and-forward system. It would be akin to voicemail or Snapchat. Wouldn't be very useful for interactive, but for something like "Hey Bob, I'm running a little late. Go ahead and order my usual for lunch" it would be alright. Of course, at that point you're probably falling back to text anyway. On 12/30/2014 02:45 PM, Tadd Torborg wrote: > Kevin, > This sounds really hopeful. Are you still working on the idea that > latency is not permitted? Or are you allowing latency? > I would really like to see this working across G8BPQ nodes. From tadd at mac.com Wed Dec 31 19:05:11 2014 From: tadd at mac.com (Tadd Torborg) Date: Wed, 31 Dec 2014 19:05:11 -0500 Subject: [Linux-ham] Opus over 9600 baud KISS TNC In-Reply-To: <54A42EDE.9000700@nivex.net> References: <92e6e5ee-f201-4654-aa3a-c5e8b70d1fb0@me.com> <54A42EDE.9000700@nivex.net> Message-ID: <552DF98F-7E86-4CE0-8CDF-06006FEEF7EE@mac.com> Kevin, My expectation is that high latency voice delivery will drive latency improvements. What I want is something that competes with Voice Over Internet using entirely ham radio digital networks. We already can buy 56kbaud digital radios at 440Mhz. I expect to use things like that to make a long haul bigger-than-statewide digital network to support linking repeaters and wholly digital mobile&base equipment. It’s taking a while to get started because we have to attract people with locations close enough to each other to make the thing work. That’s hard to do when we have almost no features or range to offer. Adding voice over G8BPQ network, even if it was impractical would at least be attractive. It would also enable using this thing mobile. Text messaging is pretty close to useless mobile. Voice may be slow but at least it is useful. The only way I have to promote this faster is to give it over to government sponsored groups and I don’t think that is the solution to growing this thing in the long term. You and I can have lots of fun with this if we can build it ourselves and make it run between ham's houses. BTW, we have a 2-port node in Bahama that can talk to your house on 6m. I’d sponsor the gear to make our TARPN work at your house if you’d do it using TARPN rules (i.e. Raspberry PI + G8BPQ + no Internet + no collisions) (see tarpn.net ), and permit another dedicated link heading out of your location to tie some other network resources in. I’m thinking 6m and 220Mhz. The antenna I’m thinking of would share one coax with 2m and 440 as well. If we wait another few weeks I’ll have less gear to lend around but I’m putting a 6m/2m/70cm node up in northwest Chapel Hill where NC86 crosses i40. That should be able to work you on 2m. There are stations in Greensboro and Burlington that want to be connected to us. I don’t have a station that can talk to Burlington yet from our side. Chapel Hill won’t do it. Neither will your house I expect, but at least it’s closer. You could probably talk on 220Mhz to a station in Mebane who CAN talk to Burlington. I’d also separately come up with gear to make two bench-top G8BPQ-on-Raspberry PI nodes if you wanted something to experiment on. I also have Wintel computers available for the same thing if that would help. I have a pair of 431Mhz 9600 baud data radios and 144Mhz 1200 baud TNCs+radios to loan if you would help. Tadd Tadd / KA2DEW tadd at mac.com Raleigh NC FM05pv “Packet networking over ham radio": http://tarpn.net Tadd Torborg tadd at mac.com > On Dec 31, 2014, at 12:14 PM, Kevin Otte wrote: > > It largely depends on what you want to do. Most of my experiments have centered around real time, point-to-multipoint comms similar to our analog voice systems. With VoIP systems you use UDP because the occasional dropped frame isn't going to go noticed. Once you add in the reliability/retransmission layer, you not only effectively half your available rate, but your end-to-end latency becomes wildly variable with network congestion. Not good for realtime. > > If we ignore the need for realtime and just want to move the voice across a NET/ROM network, you are basically looking at a store-and-forward system. It would be akin to voicemail or Snapchat. Wouldn't be very useful for interactive, but for something like "Hey Bob, I'm running a little late. Go ahead and order my usual for lunch" it would be alright. Of course, at that point you're probably falling back to text anyway. > > On 12/30/2014 02:45 PM, Tadd Torborg wrote: >> Kevin, >> This sounds really hopeful. Are you still working on the idea that >> latency is not permitted? Or are you allowing latency? >> I would really like to see this working across G8BPQ nodes. > _______________________________________________ > Linux-ham mailing list > Linux-ham at trilug.org > http://www.trilug.org/mailman/listinfo/linux-ham -------------- next part -------------- An HTML attachment was scrubbed... URL: