On May 23, 2008, at 3:38 PM, Dan Smith wrote: > > Nate, I disagree that sub channel data on air is buffered (where?) > until > > a transceiver is in RX mode. The transceiver hears real time > activity. > > Sub channel TX can be buffered in the Comms prog until TX busy > status is > > off hence subsequent TX on a auto data send setup(not ptt) or > buffered > > as in the the preferred D*chat(min line send characters) format to > > reduce the beeping by a listening unit. > > Nate is correct here. The radio has a very tiny buffer in it, and will > send an XOFF to the computer when that buffer is full. The computer > waits until the radio's BUSY sense goes off, the radio drains the > buffer > and the radio sends another XON to get things flowing again. It is a > selectable option in the radios I've seen, but I can't imagine why > you'd > turn it off. >
It's actually great for "muxing" voice and data traffic. The only thing the data transfer programs are going to need to have (eventually... yeah, another request Dan! haha...) is the ability to tag something "priority" or "non-priority" and if "priority"... go ahead and start filling up that radio buffer so it'll "grab" the channel from the voice users right away when they unkey... if "non- priority" it would be better if there were longer breaks between transmissions. Unfortunately the rig doesn't send the status (in any way that we know of) of what and who it's hearing back up the serial port to the program in its normal serial communications mode... but it's obvious that at least on the rigs where the programming software also doubles as "remote control" software that the data is AVAILABLE from the rig. It's just not documented on how to get the rig to spit it out. That won't take someone too long to reverse-engineer by putting a protocol analyzer between the programming software and the rig, probably. But whether or not you can switch the serial port back and forth between "monitoring/programming" mode and "sending/receiving serial data mode" on the fly, is the big question. I bet the serial port implementation is modal, and you "choose" to go into programming/control mode and once you're there, I don't know how you get out... but... if they implemented it as something like "escape" sequences in the design, special serial data that triggers a response from the rig, but otherwise the serial data goes out to be transmitted... that would be COOL! Interesting things could be done if it's possible to "switch on the fly", like data reception on one memory channel, copy the data, switch channels, spit it back out to someone else... build software that can be a "cross-band repeater" for data. Even cross-link two different coverage repeaters. (Yeah, I know about Dan's "IP Repeater" too, that's a nifty gadget also... radio on one end with D-RATS, IP to another D-RATS with another radio, and all data traffic passes to both sides. Neat!) But we're all still just figuring out how to get Dan's stuff to play nicely through a repeater first... baby-steps... (Dan, the guys did do another series of tests on the repeater last night. Not sure if they captured a debug log for you or not, but they petered out just before midnight. I don't think any of us have been to bed before 2AM this week! GRIN. I'm looking forward to getting "back in the game" after I'm available again early next week. One of the other things we're suspecting is that we're all in good voice coverage of the repeater, but MAYBE... just maybe... we're taking some bit errors on data at the ranges we're working from... so our results are just a bit inconsistent. On the other hand, that's probably just the type of "ugly corner case" data you love to see... the "noisy" users of any file transfer protocol (even outside of D-STAR always put the most "hurt" on the protocol and make it easier to see where it gets brittle and breaks!) -- Nate Duehr, WY0X [EMAIL PROTECTED]
