Trouble with my USB URI
I had a note up and running well with not any real issues, however after about 4-6 months, the system no longer detected carrier on the cor line. Sometimes it would think its always on and sometimes it would think its off. I checked the voltage at the line from the radio and that was working as it should. I even reprogrammed the radio to try it voltage high instead of low for carrier. This did not make any difference. I have tried several radios Radius M100 CM300. All work fine on the IRLP machine and all show proper voltage on the COS signal. I have the DMK URI with the eprom. Can anyone suggest any other diagnostics? I would like to get the Node back up and running and/or order a replacement URI Craig VA3DTF
Try downloading the uridiag program from: http://svn.ohnosec.org/viewvc/projects/allstar/uridiag/trunk/?root=svn&view=... Un-tar it and 'make' it, then run './uridiag' and use option 'c' and it will tell you how to make a connector for running the diagnostics. This is the program that DMK uses to for production testing of a URI. JIM WB6NIL Date: Sun, 15 May 2011 23:11:58 -0400 From: craig.hastings@gmail.com To: App_rpt-users@ohnosec.org Subject: [App_rpt-users] Trouble with my USB URI I had a note up and running well with not any real issues, however after about 4-6 months, the system no longer detected carrier on the cor line. Sometimes it would think its always on and sometimes it would think its off. I checked the voltage at the line from the radio and that was working as it should. I even reprogrammed the radio to try it voltage high instead of low for carrier. This did not make any difference. I have tried several radios Radius M100 CM300. All work fine on the IRLP machine and all show proper voltage on the COS signal. I have the DMK URI with the eprom. Can anyone suggest any other diagnostics? I would like to get the Node back up and running and/or order a replacement URI Craig VA3DTF _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
Thanks Jim. I will give it a try. On 16 May 2011 15:00, Jim Duuuude <telesistant@hotmail.com> wrote:
Try downloading the uridiag program from:
http://svn.ohnosec.org/viewvc/projects/allstar/uridiag/trunk/?root=svn&view=...
Un-tar it and 'make' it, then run './uridiag' and use option 'c' and it will tell you how to make a connector for running the diagnostics.
This is the program that DMK uses to for production testing of a URI.
JIM WB6NIL
------------------------------ Date: Sun, 15 May 2011 23:11:58 -0400 From: craig.hastings@gmail.com To: App_rpt-users@ohnosec.org Subject: [App_rpt-users] Trouble with my USB URI
I had a note up and running well with not any real issues, however after about 4-6 months, the system no longer detected carrier on the cor line.
Sometimes it would think its always on and sometimes it would think its off.
I checked the voltage at the line from the radio and that was working as it should.
I even reprogrammed the radio to try it voltage high instead of low for carrier. This did not make any difference.
I have tried several radios Radius M100 CM300. All work fine on the IRLP machine and all show proper voltage on the COS signal.
I have the DMK URI with the eprom.
Can anyone suggest any other diagnostics? I would like to get the Node back up and running and/or order a replacement URI
Craig VA3DTF
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
Jim - any chance that the voting system could have an option to run the receiver sound conversion at a higher sampling rate (>8000)? I am thinking it could also be used for a Dstar system - that means you need to reproduce what is coming out of the discriminator from near 0 Hz up to about 5.5 KHz with a relatively flat pass band. Ken
Unfortunately physics does not allow (for several reasons) data to be decoded from the audio as a result of any type of voting system. The only way to accomplish voting using digital audio is to decode the digital stream (at least into digital data) at the voting receiver site, *then* send the decoded audio data as packets for voting etc. JIM WB6NIL From: ke2n@cs.com To: telesistant@hotmail.com; app_rpt-users@ohnosec.org Subject: Voting Date: Mon, 30 May 2011 19:55:51 -0400 Jim – any chance that the voting system could have an option to run the receiver sound conversion at a higher sampling rate (>8000)? I am thinking it could also be used for a Dstar system – that means you need to reproduce what is coming out of the discriminator from near 0 Hz up to about 5.5 KHz with a relatively flat pass band. Ken
I suppose there will be a phase-continuity problem at the moment of switchover? You would have to synchronize the audio to the vicinity of 1 -10 microseconds probably - not 125 microseconds. RF propagation might cause this much delay . hmmm, I see the problem. The problem with decoding at the remote receivers (as I understand it) is that, if the error exceeds the correctable number of bits, you don't know you have an error. If the error is correctable - well, then why switch ? A conundrum. I suppose if you had zero error bits in one receiver and some small amount in the other receiver (2 or 3 bits in a frame - something correctable) you would want to switch the receiver that had the zero errors on the theory that the *next* frame is less likely to be trash. But there is no guarantee . the next good data frame might be coming from the receiver that had errors with the current data frame. Sigh Ken KE2N From: Jim Duuuude [mailto:telesistant@hotmail.com] Sent: Tuesday, May 31, 2011 7:05 PM To: ke2n@cs.com; app_rpt mailing list Subject: RE: Voting Unfortunately physics does not allow (for several reasons) data to be decoded from the audio as a result of any type of voting system. The only way to accomplish voting using digital audio is to decode the digital stream (at least into digital data) at the voting receiver site, *then* send the decoded audio data as packets for voting etc. JIM WB6NIL _____ From: ke2n@cs.com To: telesistant@hotmail.com; app_rpt-users@ohnosec.org Subject: Voting Date: Mon, 30 May 2011 19:55:51 -0400 Jim - any chance that the voting system could have an option to run the receiver sound conversion at a higher sampling rate (>8000)? I am thinking it could also be used for a Dstar system - that means you need to reproduce what is coming out of the discriminator from near 0 Hz up to about 5.5 KHz with a relatively flat pass band. Ken
A bit more labor-intensive approach then ... add the GMSK demod and FEC routines to the voter receiver board - assuming it has the DSP horsepower (open source code is available) when it hears D-STAR, it sends time-stamped data frames (with RSSI and maybe BER) to the D-STAR voter main program(1) when it does not hear the DSTAR sync tone, it sends uLaw audio with time stamps and RSSI to another address: the analog voter program(2) program 1 (running on some computer somewhere) receives the frames above and reconsititutes the DSTAR data (with regenerated FEC) and streams it to the DSTAR repeater address and port. program 2 (running on some computer somewhere) reassembles the audio stream and produces audio for the Asterisk analog repeater. Programs 1 and 2 could be the same program actually ... Ken -----Original Message----- From: Jim Duuuude <telesistant@hotmail.com> To: ke2n <ke2n@cs.com>; app_rpt mailing list <app_rpt-users@ohnosec.org> Sent: Tue, May 31, 2011 7:05 pm Subject: RE: Voting Unfortunately physics does not allow (for several reasons) data to be decoded from the audio as a result of any type of voting system. The only way to accomplish voting using digital audio is to decode the digital stream (at least into digital data) at the voting receiver site, *then* send the decoded audio data as packets for voting etc. JIM WB6NIL From: ke2n@cs.com To: telesistant@hotmail.com; app_rpt-users@ohnosec.org Subject: Voting Date: Mon, 30 May 2011 19:55:51 -0400 Jim – any chance that the voting system could have an option to run the receiver sound conversion at a higher sampling rate (>8000)? I am thinking it could also be used for a Dstar system – that means you need to reproduce what is coming out of the discriminator from near 0 Hz up to about 5.5 KHz with a relatively flat pass band. Ken
Some time ago, I posted something about the elements of a long-ish macro not executing in the right sequence (such as playing recorded segments in the wrong order and just blowing-by remote commands without executing them properly). I never got any replies. Eventually I found that I could run the whole thing as a Linux script with interspersed "sleep" commands and make it all work properly - like this ..... ..... /usr/sbin/asterisk -rx "rpt fun 27021 *4533" ; remote command for 53MHz node sleep 5 /usr/sbin/asterisk -rx "rpt fun 27021 *6601#" ; put node 533 into bulletin mode (SS1) sleep 5 /usr/sbin/asterisk -rx "rpt fun 27021 *9913" ; play the recording sleep 22m (this last one plays ARRL Audio News). ..... ..... This worked reliably when called from crontab, but there was no way to run it from DTMF. Recently, I found out about the "cmd" instruction - I thought "aha!) 9911=cmd,/usr/local/sbin/do_arrl.sh But it seems that the script calls asterisk (from within asterisk) the whole thing goes into some sort of infinite loop. It does seem to have executed the asterisk -rx calls at least 5 times before things went pear shaped. So: is this the expected behavior? Is there a command line option on the asterisk calls that can avoid the problem? Is there a different way to accomplish this? Tnx Ken KE2N
OK - I think I see the problem In the actual case, it looks like the function number to command the script was the same function number the script was using to play the recording. In other words I really did program it to loop. As I say sometimes .. that's why I don't do this for a living 73 Ken
participants (3)
-
Craig Hastings -
Jim Duuuude -
Ken