Page 1 of 1

Strange compatibility problem between makes

PostPosted: Mon Oct 09, 2017 9:16 pm
by G4RMT
This has been making me scratch my head.

Radioddity GD-77
Retevis RT-82
2 x MD-380

All programmed simplex digital, identical zones and settings.

Mostly, they work properly - all able to talk to each other, and all their IDs come up on the other displays as you'd expect - apart from sometimes the GD-77 stays silent. BUT - only when a call is initiated from either of the 380s. The Retevis receives it, as does the other 380, but the GD-77 doesn't.

All the other radios can hear the GD-77. However, if the GD-77, after transmitting still has the display light on, it WILL receive any of the others? As soon as the display goes out, the MD-380s cannot perk it up again - but the RT-82 can?

So the upshot is that something in the 380s programming is either missing, or present when it shouldn't be, and I can't think what it is? However, whatever is causing it, is defeated by the radio being somehow 'awake', but the 380 are missing the ability to wake the GD-77 up? I just cannot work out what is going on at all. There is another frequency programmed into the VHF section of the GD-77, and this was active occasionally while I was having the problem. Could the GD-77, be doing a dual watch type thing, and giving emphasis to the VHF section, despite the display showing the UHF channel is selected?

I'm not sure anyone who doesn't have two radios will have experienced this. Tomorrow, I'll remove the VHF programming leaving just the UHF and see if this sorts it. I don't know why I added both sets of frequencies to A and B, I just don't think it mattered? Maybe this is the problem - but I don't know.

Re: Strange compatibility problem between makes

PostPosted: Fri Oct 13, 2017 9:44 pm
by Richie_asg1
I'm only a newbie so this is just a suggestion based on my very limited experience.

Is there a protocol during the initial transmit of the identifier that transmits a number of times and then waits before continuous transmission? If so it could be a timing or instability issue during this phase.

I only say this because I had a problem recently making a remote sensor for security cameras. The idea was simple - put a microwave sensor on the back of the landrover that would transmit a 433Mhz signal to a receiver in a DVR recorder indoors, that would then turn on cameras and IR lighting to see who is near the vehicle. As I was using an arduino to process timing of the transmit signal so that it would be a 1/2 second pulse and then wait for a minute so it doesn't constantly transmit, I thought I would use the Arduino to provide the coding pulses rather than a code chip.
This proved harder than I imagined as the receiver had a period of time where it would hear signals but needed time to fully "wake up" and start decoding useful data. It was the timing that was the hardest part to get right, and needed a preamble of pulses before transmitting coded data.

Possible yours may use different timing protocol or have instability issues causing several of the first data pulses to be misshaped or noisy, and if it can't identify the signal then it may ignore it.
Have you tried them all on clean DC supplies? No nasty USB chargers nearby?

I used a scope to see the pulses properly and decode their timing, then program the Arduino to replicate them.

You could sniff the transmit data to see if they are the same or if there are obvious Signal to Noise issues.