[DSTAR_DIGITAL] Re: Beeps
There are other reasons why the radio may generate a beep. The main one is loss of bit-sync. Every 21st frame has 0x55 0x2d 0x16 at the end - if you generate these at 20 or 22 frame intervals, sure enough, you get a beep. If you miss several, you get a beep. So, under weak conditions, you can hear more beeps as the radio struggles to re-sync the bit-stream. Spoken from coding experience of someone who has spent the last 12 months counting in 12 bytes x 21 frames :-) David --- In dstar_digital@yahoogroups.com, Neil barrym...@... wrote: The beeps are generated (by the radio) when it 'thinks' the signal being recieved has finished, like a 'clear to send' request. Due to our really patchy coverage here in the UK, I experience many 'beeps' from the repeaters stream, while it drops in and out of range, it has nothing to do with what you are listening to, so same with simplex. Neil. - Original Message - From: Nate Duehr n...@... To: Justin G0KSC jus...@... Cc: dstar_digital@yahoogroups.com Sent: Wednesday, October 14, 2009 3:15 PM Subject: Re: [DSTAR_DIGITAL] Beeps Technically this is also true. The beeps are just an indication that signal has dropped, and a configurable feature on some of the rigs to turn it off or change its volume level from the speaker. The information shown on the SCREEN however, is the actual notification about what the system thinks is going on. On Oct 14, 2009, at 8:00 AM, Justin G0KSC wrote: I think you will find the bleeps are from your radio. The receiver bleeps to notify you a DV signal has dropped, not the repeater. Try a simplex QSO, this will confirm this for you. - Original Message - From: Robbie De Lise To: dstar_digital@yahoogroups.com Sent: Wednesday, October 14, 2009 2:52 PM Subject: Re: [DSTAR_DIGITAL] Beeps As I experience it i think something like this: No beep: The repeater did not confirm your TX, prolly no RX on the repeater side 1st beep: The repeater (CALL A, B or C) confirms your TX 2nd beep: The gateway (CALL G) confirms your TX. Ofcourse, when someone pushes the PTT right after the BEEP or before the BEEP, the repeater does not have the time to send the confirmation out. (The confirmations are send seperately from the DV transmission) so: DV TX stop TX Confirm Repeater TX (BEEP) stop TX Confirm Gateway TX (BEEP) stop TX if someone pushes the mike faster its like: DV TX stop TX Confirm Repeater TX (BEEP) stop TX DV TX stop TX Confirm Repeater TX (BEEP) stop TX Confirm Gateway TX (BEEP) stop TX or even: DV TX stop TX DV TX stop TX Confirm Repeater TX (BEEP) stop TX Confirm Gateway TX (BEEP) stop TX I could also be completely wrong :) Let me know if someone else has the same experience. 73s Robbie On Wed, Oct 14, 2009 at 3:42 PM, Fran Miele f...@... wrote: Several of the users on our system have been discussing the beeps heard on a repeater and it is clear we really don't understand them. I'm sure this has been asked many times before but I can't seem to find a definite answer. Can someone explain the beeps that are heard at the end of a transmission on a repeater? Sometimes there are two, sometimes one and sometimes none. What do they mean, and why the variation? Thanks in advance, Fran, W1FJM Nate Duehr n...@... facebook.com/denverpilot twitter.com/denverpilot Please TRIM your replies or set your email program not to include the original message in reply unless needed for clarity. ThanksYahoo! Groups Links
Re: [DSTAR_DIGITAL] Re: Beeps
On Oct 16, 2009, at 9:22 PM, Woodrick, Ed wrote: The “ignoring the call if it can’t be decoded” IS the attempt to assure that the protocol works. That allows subsequent transmissions to follow the initial transmission. If this didn’t occur, then there would be a lot more “dropped transmissions” It’s only when the two stations have different routing in which it becomes a big issue. And in general, subsequent transmissions should all have the same routing, just maybe a different source callsign. So as much as you think that it’s broken, I think that Icom did the right thing. I didn't say they did the wrong thing in the context of how they handle it -- once they were stuck with the protocol. I'm saying they did the only thing they could with a busted underlying protocol. One that once put into the field, is shown to not take enough care of the 2nd most important data in the transmission other than the voice... the routing data. Since Internet GW seems MAYBE to not have been an initial design goal, since RPT1 and RPT2 are just fields to be used as desired... and it's likely the GW implementation came along much later after the protocol was designed... there probably was little forethought to how important the routing fields would someday be. Since the GW is after all, a proprietary software package from Icom... there may have never been any thought to how weak signals would destroy the information needed to implement such a connectivity system. And by the time they try it out, they realize... Oh no... we have to pretend a mangled header is a continuation of the last transmission, because it might just be mobile flutter/dropouts. Bummer! So yes, you can see how an Icom engineer backed into a corner by a protocol that drops header information like water out of a bucket that has holes drilled in the bottom... would have to do exactly what they did. All I'm saying is that if you look far enough back, ultimately... the only CORRECT fix -- was always to fix the protocol's handling of header information to make it more robust.. In other words, if the on-air protocol is weak, the rest of the system above it, suffers. (Depending on WHEN we think Icom and JARL really started work the D- STAR specification, there may already have been published studies that interlacing the routing data was the correct way to go. Was it in development before the APCO P-25 folks published their protocol? I don't know. If it was the same timeframe, that's embarassing... they ignored other group's test data. Never a good idea when building a new type of tech.) As far as D-STAR the protocol goes, the proper root-cause fixes can't be done now, without obsoleting rigs -- so I'm just discussing this in light of learning how to build the NEXT protocol. If there ever is a next one... for Amateur Radio. Again not a good/bad emotional judgment, just analysis of the good/ bad points of the protocol, as implemented... and compared to others attempting similar end-results. -- Nate Duehr, WY0X n...@natetech.com Please TRIM your replies or set your email program not to include the original message in reply unless needed for clarity. ThanksYahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/dstar_digital/ * Your email settings: Individual Email | Traditional * To change settings online go to: http://groups.yahoo.com/group/dstar_digital/join (Yahoo! ID required) * To change settings via email: mailto:dstar_digital-dig...@yahoogroups.com mailto:dstar_digital-fullfeatu...@yahoogroups.com * To unsubscribe from this group, send an email to: dstar_digital-unsubscr...@yahoogroups.com * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [DSTAR_DIGITAL] Re: Beeps
That is not what I read in previous discussions by folks who were actually doing protocol-level work, but if you insist that the headers are encapsulated inside the portion of the stream that's covered by FEC, I can't really refute it technically. What I can be sure of, is that the statement makes no sense. If a voice is copyable in a signal, but the header was mangled, that would certainly appear that either: a) FEC wasn't applied to the header. b) The way the FEC was applied to the header/the way the protocol handles header/callsign information is... well, busted. c) Voice is copyable by the human ear even with artifacts from errors. But we all already knew the b) version of that, anyway. Headers should have been continuously interlaced in the slow data field or actually designed into the protocol as a continuous repetitive stream, so the GW software and controller firmware could have been designed to pick up mid-stream if a copyable version of the callsigns were to pass a CRC (or other mathematical) check in the middle of a transmission, after missing the header completely at the beginning of one. It's also too bad that the repeaters weren't designed for field firmware updates. If they were, they could at least be patched to watch the slow-speed data callsigns, but my understanding is that only Your Call is sent in that way, not the UR, RPT1, or RPT2... so I can see why it wouldn't really matter if the Controller or GW had visibility to it. It seems to have been added only to help the receiving radio. In layman's terms, and in how we all know the system behaves in the wild: Callsign headers from mobile/weak stations get missed, far too often. And that led to the GW design allowing tailgating to handle mobile drop out at the critical time at the beginning of the transmission. Those two statements pretty much cover it without getting overly technical for those not interested... D-STAR is a great learning experience for the NEXT major mobile digital mode. Nothing wrong with it that couldn't easily be fixed with protocol changes to match current telecom protocol best practices. -- Nate Duehr, WY0X n...@natetech.com On Wed, 14 Oct 2009 21:23 +, Jonathan Naylor naylo...@yahoo.com wrote: Hi Nate You're wrong about the callsigns in the header not having FEC, they are. In fact they're probably better protected than the AMBE data if you equate the amount of protection with the extra data added for the FEC. What is not protected is the header data that is repeated in the slow data field, but AFAIK the repeater itself doesn't use that. Jonathan G4KLX __._,_._
Re: [DSTAR_DIGITAL] Re: Beeps
At 07:20 AM 10/17/2009, you wrote: That is not what I read in previous discussions by folks who were actually doing protocol-level work, but if you insist that the headers are encapsulated inside the portion of the stream that's covered by FEC, I can't really refute it technically. My understanding is that the voice uses the FEC built into the AMBE vocoder, which the headers don't have access to. 73 de VK3JED / VK3IRL http://vkradio.com
Re: [DSTAR_DIGITAL] Re: Beeps
My reading of the protocol specification is that the header has a checksum (2.1.1 (11) page 4 - http://www.arrl.org/FandES/field/regulations/techchar/D-STAR.pdf) for error detection, but forward error correction (FEC) only applies to the audio portion of the AMBE payload (and performed by the AMBE chip). On Oct 16, 2009, at 2:09 PM, Tony Langdon wrote: At 07:20 AM 10/17/2009, you wrote: That is not what I read in previous discussions by folks who were actually doing protocol-level work, but if you insist that the headers are encapsulated inside the portion of the stream that's covered by FEC, I can't really refute it technically. My understanding is that the voice uses the FEC built into the AMBE vocoder, which the headers don't have access to. 73 de VK3JED / VK3IRL http://vkradio.com John D. Hays Amateur Radio Station K7VE PO Box 1223 Edmonds, WA 98020-1223 VOIP/SIP: j...@hays.org Email: j...@hays.org
RE: [DSTAR_DIGITAL] Re: Beeps
I see empty callsigns displayed all the time on weak signals (HT's usually) on the receiving radio (error detection... it was bad, so... chuck it), and in the D-Plus logs on the W0CDS Gateway, all the time. Never on strong signals. In fact, seeing the callsign go missing is a great way for me (as a system admin of a Gateway, but there's no visibility to people who can't see the D-Plus log, maybe I should figure out a way to publish that on the web) to tell someone's NEVER going to be able to pass D-RATS traffic... their data is already far too mangled. A way for users to test this (although possibly annoying for those listening) is to send DIFFERENT commands to D-Plus back to back. If you send a command and get the expected message back for the PREVIOUS command you sent... your headers are mangled. (I've run into this taking down a D-Plus link while mobile and heard it happen to a number of people. Send the command, then switch back to CQCQCQ and get Not currently linked after transmission #2. This means D-Plus thought you sent the original command over again, and didn't see CQCQCQ. Sadly, this is HIGHLY confusing for users.) -- Nate Duehr, WY0X n...@natetech.com On Fri, 16 Oct 2009 21:25 +, Woodrick, Ed ewoodr...@ed-com.com wrote: And you can tell that there is some error detection/correction because how often do you see a bad call sign displayed? If there wasn’t, you’d see also sorts of crap in the Last Heard list. Ed WA4YIH From: dstar_digi...@yahoogroups. com [mailto:dstar_digi...@yahoogroups.com] On Behalf Of Tony Langdon Sent: Friday, October 16, 2009 5:09 PM To: dstar_digi...@yahoogroups.comsubject: Re: [DSTAR_DIGITAL] Re: Beeps At 07:20 AM 10/17/2009, you wrote: That is not what I read in previous discussions by folks who were actually doing protocol-level work, but if you insist that the headers are encapsulated inside the portion of the stream that's covered by FEC, I can't really refute it technically. My understanding is that the voice uses the FEC built into the AMBE vocoder, which the headers don't have access to. 73 de VK3JED / VK3IRL [1]http://vkradio.com References 1. http://vkradio.com/ 2. http://groups.yahoo.com/group/dstar_digital/message/9044;_ylc=X3oDMTM1NDA5anFtBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARtc2dJZAM5MDg4BHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTI1NTcyODMyNAR0cGNJZAM5MDQ0 3. http://groups.yahoo.com/group/dstar_digital/post;_ylc=X3oDMTJxYnNxNDQ1BF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARtc2dJZAM5MDg4BHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTI1NTcyODMyNA--?act=replymessageNum=9088 4. http://groups.yahoo.com/group/dstar_digital/post;_ylc=X3oDMTJmZmVraWhvBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNudHBjBHN0aW1lAzEyNTU3MjgzMjQ- 5. http://groups.yahoo.com/group/dstar_digital/messages;_ylc=X3oDMTJmdWxyaWhsBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNtc2dzBHN0aW1lAzEyNTU3MjgzMjQ- 6. http://groups.yahoo.com/group/dstar_digital/files;_ylc=X3oDMTJnZWFpdnJqBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNmaWxlcwRzdGltZQMxMjU1NzI4MzI0 7. http://groups.yahoo.com/group/dstar_digital/photos;_ylc=X3oDMTJmOW9oNHNvBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNwaG90BHN0aW1lAzEyNTU3MjgzMjQ- 8. http://groups.yahoo.com/group/dstar_digital/links;_ylc=X3oDMTJnY2dmcW0xBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNsaW5rcwRzdGltZQMxMjU1NzI4MzI0 9. http://groups.yahoo.com/group/dstar_digital/database;_ylc=X3oDMTJkcjMzZWJiBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNkYgRzdGltZQMxMjU1NzI4MzI0 10. http://groups.yahoo.com/group/dstar_digital/polls;_ylc=X3oDMTJnNHExNHNoBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNwb2xscwRzdGltZQMxMjU1NzI4MzI0 11. http://groups.yahoo.com/group/dstar_digital/calendar;_ylc=X3oDMTJlbzEybHZvBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNjYWwEc3RpbWUDMTI1NTcyODMyNA-- 12. http://groups.yahoo.com/;_ylc=X3oDMTJlZjdqOW45BF9TAzk3NDc2NTkwBGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTI1NTcyODMyNA-- 13. http://groups.yahoo.com/group/dstar_digital/join;_ylc=X3oDMTJnMGJuZXZpBF9TAzk3NDc2NTkwBGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNzdG5ncwRzdGltZQMxMjU1NzI4MzI0 14. mailto:dstar_digital-dig...@yahoogroups.com?subject=email%20delivery:%20Digest 15. mailto:dstar_digital-traditio...@yahoogroups.com?subject=change%20delivery%20format:%20Traditional 16. http://groups.yahoo.com/group/dstar_digital;_ylc=X3oDMTJlMWMwc2QxBF9TAzk3NDc2NTkwBGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNocGYEc3RpbWUDMTI1NTcyODMyNA-- 17. http://docs.yahoo.com/info/terms/ 18. mailto:dstar_digital-unsubscr...@yahoogroups.com?subject= 19. http://groups.yahoo.com/group/dstar_digital/members;_ylc
[DSTAR_DIGITAL] Re: Beeps
Nate, If you look at the D-Star protocol you'll see in AP2 (in the file shogen.pdf) the details of the FEC applied to the header, doubling its length to 660 bits. It's a convolution code as opposed to concatenated block codes as used by AMBE. The checksum in the header is then used to ensure that the header FEC has done its job. The header data is repeated in the slow data throughout the transmission but without FEC but with the checksum. There is no excuse for a receiving station to get a corrupted callsign bar bad programming. Jonathan G4KLX
Re: [DSTAR_DIGITAL] Re: Beeps
Okay, interesting. Please review and note that I never said a receiving station gets a CORRUPTED callsign. The result is actually that the receiving station gets *no callsign* at all. Then the firmware in the controller or the software in the GW was programmed in such a way as to treat that missing header as if the prior transmission had never unkeyed, EVEN THOUGH there was a non-corrupted, perfectly copyable END to the prior transmission. (D-STAR does end-of-transmission correctly by the way, transmissions don't just stop, there's a defined I'm done transmitting pattern. But if the overlying network ignores that data, or it isn't passed far enough up the stack to where things like the GW have visibility to it, it's wasted.) The result is the same, the system breaks and has no way to self-recover. Streaming protocols that include routing information in the stream (source-routed) need to try a little harder to get the required information for the system to work, to the far-end. Especially over a physical medium as unpredictable as RF. That or they need to throw out the ENTIRE transmission and try again. (Which of course, would be completely annoying and non-workable for people used to analog FM.) Basically, I'm saying this isn't Ethernet/copper wire this data's passing over, and a protocol designed for a noisy medium can't just send the header/routing information once, or it's bound to be a very brittle protocol as most protocol engineers would state it. It is. Very brittle. There are plenty of protocols that do work in heinous amounts of physical layer noise... D-STAR's not one of them. That's not a bad/good judgment against D-STAR, it just is... -- Nate Duehr, WY0X n...@natetech.com On Fri, 16 Oct 2009 22:32 +, Jonathan Naylor naylo...@yahoo.com wrote: Nate, If you look at the D-Star protocol you'll see in AP2 (in the file shogen.pdf) the details of the FEC applied to the header, doubling its length to 660 bits. It's a convolution code as opposed to concatenated block codes as used by AMBE. The checksum in the header is then used to ensure that the header FEC has done its job. The header data is repeated in the slow data throughout the transmission but without FEC but with the checksum. There is no excuse for a receiving station to get a corrupted callsign bar bad programming. Jonathan G4KLX References 1. http://groups.yahoo.com/group/dstar_digital/message/9044;_ylc=X3oDMTM1b3E1YzFwBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARtc2dJZAM5MDkwBHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTI1NTczMjQxMAR0cGNJZAM5MDQ0 2. http://groups.yahoo.com/group/dstar_digital/post;_ylc=X3oDMTJxOTRjY2k3BF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARtc2dJZAM5MDkwBHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTI1NTczMjQxMA--?act=replymessageNum=9090 3. http://groups.yahoo.com/group/dstar_digital/post;_ylc=X3oDMTJmcTlodTFqBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNudHBjBHN0aW1lAzEyNTU3MzI0MTA- 4. http://groups.yahoo.com/group/dstar_digital/messages;_ylc=X3oDMTJmNGg0bTNyBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNtc2dzBHN0aW1lAzEyNTU3MzI0MTA- 5. http://groups.yahoo.com/group/dstar_digital/files;_ylc=X3oDMTJnMm9kYmQ5BF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNmaWxlcwRzdGltZQMxMjU1NzMyNDEw 6. http://groups.yahoo.com/group/dstar_digital/photos;_ylc=X3oDMTJmcmtodGIzBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNwaG90BHN0aW1lAzEyNTU3MzI0MTA- 7. http://groups.yahoo.com/group/dstar_digital/links;_ylc=X3oDMTJnM2hqbnE5BF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNsaW5rcwRzdGltZQMxMjU1NzMyNDEw 8. http://groups.yahoo.com/group/dstar_digital/database;_ylc=X3oDMTJkM2ZpbDM1BF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNkYgRzdGltZQMxMjU1NzMyNDEw 9. http://groups.yahoo.com/group/dstar_digital/polls;_ylc=X3oDMTJnZ3Y5Z2xmBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNwb2xscwRzdGltZQMxMjU1NzMyNDEw 10. http://groups.yahoo.com/group/dstar_digital/calendar;_ylc=X3oDMTJlNXUxa2QxBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNjYWwEc3RpbWUDMTI1NTczMjQxMA-- 11. http://groups.yahoo.com/;_ylc=X3oDMTJlODBqYTdrBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTI1NTczMjQxMA-- 12. http://groups.yahoo.com/group/dstar_digital/join;_ylc=X3oDMTJnYnU4cXI2BF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNzdG5ncwRzdGltZQMxMjU1NzMyNDEw 13. mailto:dstar_digital-dig...@yahoogroups.com?subject=email%20delivery:%20Digest 14. mailto:dstar_digital-traditio...@yahoogroups.com?subject=change%20delivery%20format:%20Traditional 15.
[DSTAR_DIGITAL] Re: Beeps
Hi Nate You're wrong about the callsigns in the header not having FEC, they are. In fact they're probably better protected than the AMBE data if you equate the amount of protection with the extra data added for the FEC. What is not protected is the header data that is repeated in the slow data field, but AFAIK the repeater itself doesn't use that. Jonathan G4KLX
