Hi all I’m new and have a big problem with my TH-D7 and I can’t find any help locating the cos .
can someone help me otherwise i can’t start my node
unfortunately I’m not a technician and I’m getting by but I don’t know where to put my hands.
configured everything … the node speaks … receives … but without COS it does not start .
Use the usbradio driver and set carrierfrom=vox. That works great with HTs to provide COS detection without an actual COS input.
ok I’ll try and then I’ll tell you thanks in the meantime.
tried but it doesn’t work for me so it’s left to ask if anyone has a way to trick the cos otherwise it’s a big problem.
VOX is not really a good option. But it is an option as well as using usbradio and PL tone for cos. Should be in the wiki I think.
In the event you do not get a exact reply,
You will need to get a schematic of the radio and prepare to do surgery in finding the point in the squelch circuit that toggles voltage when the squelch gate opens/closes and connect that to the COS line of your URI. And handle carefully not to draw to much current in your circuit. Using a buffer transistor is a plus.
Not an easy task for beginners.
If no good reply, I might suggest you try a mobile radio where the parts and room are larger for you to work in without error. Perhaps one that either has an interface you can attach to or is documented for the same.
But I understand we all have limitations of different sorts.
Perhaps since I have bumped this up the list, you might get an exacting reply yet.
hello Mike thanks for the support morle …yes the vox is not working much …!
I tried to look for a point where to take a useful signal but … I can’t weld anything … due to limited space.
now last test I want to see if using the radio status LED I get something.
certainly strange that no one has tried … I discovered that it was also used for satellite use (cie two thd7 devices were used on board a satellite, but I can’t find any useful diagrams.
continuous .
While not familiar with the radio, a LED indicator of open squelch is the easy and best choice if it has it.
But I still suggest using a buffer transistor like a 2N3904 or 2N3906 / NPN PNP.
The logic of the cos can be a bit confusing with a URI and the software. But one step at a time.
Unfortunately nothing to do is wrong. You have to figure out how to get around the COR obstacle.
even the Vox cannot be configured … that is, the system understands the input signal … it retransmits it … everything is ok … then out of the blue … …the monitor "supermon or allmon " detect cos-signal…and the node remains in tx online…nice mess.
Not sure I understand entirely, but perhaps a little.
First, your Allmon or Supermon monitor is just that, a monitor.
It does not do any detecting for the system, just reflects what the system is detecting.
I think perhaps your logic you are seeing/using is inverted.
To better understand, you can use any low voltage device 5vdc and toggle the cos line and watch the result on the monitor of your choice. Or bump test it to ground for low active tests.
So, don’t forget the logic in your file…
Here is a copy of options I keep in my file and I un-comment what I use
; Receiver parameters simpleusb /usbradio
;carrierfrom=no
;carrierfrom=dsp
;carrierfrom=pp
carrierfrom=ppinvert
;carrierfrom=usb
;carrierfrom=usbinvert
;carrierfrom=vox
But you can see that most have a ‘invert’ of the same which changes the logic high/low when active.
If you can not get the logic to match the input, you may need a transistor to hardware invert it first.
Take your time and think about it. It is tough to grasp these concepts at first.
But you are looking for the audio to pass when the cos is active with whatever logic plan you use.
If inverted, you will see the ptt but no audio from radio input.
then there are updates:
- the vox works and is fine
it took a bit of tweaking now it goes with the right queue and the system recognizes when it receives a call.
the problem is that the system cyclically detects a “signal input --yes” … it lasts about 7/10 sec …then it ends and rightly sends the confirmation of end of receipt … …??? (logically the radio has not received anything)
when he does this … if a call comes in he receives it and sends it via the “internet” and when it ends everything resumes after a pause … in which no one speaks and the cycle starts again…?
it almost seems like there is a system watchdog that …a mess …!
or tested it beyond the real … even with the parrot …
then cyclical … it receives a “ghost signal” if it receives a radio call it hears it … when I hear it again … I will have a silent signal for x sec… and then the speech .
but…!!!
While I am talking out my rear I think, so I’m not sure this will help under these circumstances,
you might try
rxondelay=12 (ea number is a 20ms delay so this is 240ms or about a quarter second)
Probably not suggested to run higher than 25, but tests are tests.
The wiki has some limited info on this as it is used for more than as stated.
https://wiki.allstarlink.org/wiki/Troubleshooting#Breaking_the_keying_loop_between_two_simplex_nodes
It is a delay of when a signal presents itself and the system registers a active cor. It does not normally delay the audio, but if this works on VOX, you will loose the first Xms of active voice. So you can see that it eliminates some falseing from quick pulses. Could be climbing on the audio line from the radio or computer.
But this is VOX so I don’t know if it has any play here or not but worth a try.
In any case, if it is persistent, you will have to find it’s source and that could be from some switching transistor or even diode / relay throwing off a little rfi/emi pulse being picked up by the rx’r.
Separation distance and shielding help but you may need some capacitive item to sink the pulse below threshold.
All just things to think about as I can’t see this as well as you. And I’m guessing.
In any case, let us know if you find it so it may help others.
ok i’ll try and then i’ll tell you.
thanks for now