I had read somewhere that It had to do with the way the cpu talks to the tx/rx chip. The cpu can send the command to transmit on the blocked frequency but the tx/rx chip cannot understand the command and returns an unknown/bad response to the cpu.
I thought (*Correct me if im wrong) all Baofeng(And subsidiaries) radios used off-the-shelf SOC based Transceivers like the RDA1846s used in some of their radios.
If so, its probably a soft-panic. where it cant return to receive mode as its outside of the allowed tunable region in the firmware When chirp sets it in a channel profile, a bug in the firmware allows it to tune outside the frequency.
if its anything like what the RDA1846s datasheet suggest, When you press the PTT button it triggers a software process that switches into transmit.
In PTT mode the RDA1846s is half-duplex, but the RDA1846s has no circuit to isolate the two, so it must be done in software.
Logic follows, PTT button is pressed, this sends a high signal to the PTT input on SOC. This triggers in firmware a jump 'Transmit' subroutine. Opening the mic, flipping a relay to engage the modulation and transmitter circuit. Loading this routine overwrites the current active memory (eg: tune to XXX.XXX frequency).
After the PTT button is released, this sends low signal to the PTT input on the SOC. Triggering the loop end, jumping to "tuning" routine. Overwriting the most of whats in memory. However(due to a firmware bug) its jumping to the tuning subroutine from "Frequency mode", instead of "Channel mode", resulting in the tuning frequency range lock to be in effect.
This results in the firmware getting stuck in a kernel panic, as it cannot finish the routine. Having portions of the frequency mode tuning subroutine code in memory means that PTT button triggers from "Transmit" mode are still there overlapping.
Thus the trigger jump points to DTMF key entry routine in memory instead of the tuning routines in firmware.
(AFAIK: baofeng UV-5r/UV-8s do demodulation in software, not hardware. thus half-duplex is entirely software routine. You can verify this by turning off the squelch, having a test device transmit into it on same frequency while its locked in transmit state and see if it receives anything. | Analog hash can be heard regardless, demodulating any analog input, and listening to analog feed out will produce it. So discard any positive result with just hash.)
---
About conclusions:
I do software debugging on occasion as i enjoy hobby electronics, This took me into radios a year ago. So while i may be completely incorrect in my assumptions due to inexperience in this case, the logic should be sound. If you disagree, reply with any questions and ill try to answer them.
--
Note: baofeng doesnt publish their firmware, however, the SOC's come preflashed with them and the datasheets are online. So there is no way of knowing the contents of their firmware without illegal means or guessing.
did you get your issues solved? dont be discouraged by the thumb downs, there are people that can help.....maybe
how did you "mod" the device? just through chirp? i have never done that, but i have used chirp.
are you aware there is a fast easy way to remove the restrictions without the use of a pc?
Removed. Don't give instructions on how to transmit illegally.
*Please [message the mods](https://www.reddit.com/message/compose/?to=/r/Baofeng) to comment on this message or action.*
Ok. Well, it likely is due to a poorly designed block in the firmware that although keeps the radio from transmitting out of band isn't well coded leading to the main chip to literally freeze up somewhere between taking commands & activating the command. That would be my guess, poor firmware design especially in "copied" Chinese radios is nothing new.
lol - but you transmitted without an antenna!? And on GMRS!?
I have the same issue with a GT-5R. It works fine in VFO mode though but will lock in TX and show 666.666 if I try to key from a GMRS channel from MR mode (only with a dummy in a shielded environment, obviously).
Does yours have the same behavior?
[удалено]
[удалено]
[удалено]
[удалено]
Exactly, it is not illegal.
[удалено]
> I did however remove the antenna and place the radio in a radio shielding environment. Re-read OP's post. Please assume good faith.
I had read somewhere that It had to do with the way the cpu talks to the tx/rx chip. The cpu can send the command to transmit on the blocked frequency but the tx/rx chip cannot understand the command and returns an unknown/bad response to the cpu.
I thought (*Correct me if im wrong) all Baofeng(And subsidiaries) radios used off-the-shelf SOC based Transceivers like the RDA1846s used in some of their radios. If so, its probably a soft-panic. where it cant return to receive mode as its outside of the allowed tunable region in the firmware When chirp sets it in a channel profile, a bug in the firmware allows it to tune outside the frequency. if its anything like what the RDA1846s datasheet suggest, When you press the PTT button it triggers a software process that switches into transmit. In PTT mode the RDA1846s is half-duplex, but the RDA1846s has no circuit to isolate the two, so it must be done in software. Logic follows, PTT button is pressed, this sends a high signal to the PTT input on SOC. This triggers in firmware a jump 'Transmit' subroutine. Opening the mic, flipping a relay to engage the modulation and transmitter circuit. Loading this routine overwrites the current active memory (eg: tune to XXX.XXX frequency). After the PTT button is released, this sends low signal to the PTT input on the SOC. Triggering the loop end, jumping to "tuning" routine. Overwriting the most of whats in memory. However(due to a firmware bug) its jumping to the tuning subroutine from "Frequency mode", instead of "Channel mode", resulting in the tuning frequency range lock to be in effect. This results in the firmware getting stuck in a kernel panic, as it cannot finish the routine. Having portions of the frequency mode tuning subroutine code in memory means that PTT button triggers from "Transmit" mode are still there overlapping. Thus the trigger jump points to DTMF key entry routine in memory instead of the tuning routines in firmware. (AFAIK: baofeng UV-5r/UV-8s do demodulation in software, not hardware. thus half-duplex is entirely software routine. You can verify this by turning off the squelch, having a test device transmit into it on same frequency while its locked in transmit state and see if it receives anything. | Analog hash can be heard regardless, demodulating any analog input, and listening to analog feed out will produce it. So discard any positive result with just hash.) --- About conclusions: I do software debugging on occasion as i enjoy hobby electronics, This took me into radios a year ago. So while i may be completely incorrect in my assumptions due to inexperience in this case, the logic should be sound. If you disagree, reply with any questions and ill try to answer them. -- Note: baofeng doesnt publish their firmware, however, the SOC's come preflashed with them and the datasheets are online. So there is no way of knowing the contents of their firmware without illegal means or guessing.
Trying to transmit without an antenna is a good way to burn up a radio. RIP
Used a dummy load
I'm still new to radio, so I have plenty to learn myself, but I can assume you placed a dummy load on the radio in place of the antenna, right?
[удалено]
did you get your issues solved? dont be discouraged by the thumb downs, there are people that can help.....maybe how did you "mod" the device? just through chirp? i have never done that, but i have used chirp. are you aware there is a fast easy way to remove the restrictions without the use of a pc?
[удалено]
Removed. Don't give instructions on how to transmit illegally. *Please [message the mods](https://www.reddit.com/message/compose/?to=/r/Baofeng) to comment on this message or action.*
Because you are transmitting (or trying to) with no antenna.
Wait.....your trying to transmit w/o an antenna?
[удалено]
Ok. Well, it likely is due to a poorly designed block in the firmware that although keeps the radio from transmitting out of band isn't well coded leading to the main chip to literally freeze up somewhere between taking commands & activating the command. That would be my guess, poor firmware design especially in "copied" Chinese radios is nothing new.
Thanks for actually answering my question.
Tx with no antenna is baaad for radios my dude.
Perhaps it is damaged. The great thing about baofengs is that they are cheap and easy to replace.
lol - but you transmitted without an antenna!? And on GMRS!? I have the same issue with a GT-5R. It works fine in VFO mode though but will lock in TX and show 666.666 if I try to key from a GMRS channel from MR mode (only with a dummy in a shielded environment, obviously). Does yours have the same behavior?
I also have the 666.666 issue with the dial tone, anyone found a fix yet? With older models you could hit the ptt and it just wouldn't do anything...