Feature Request: Hardware COS for Baofeng UV-5R

[rxt1077]

I just wanted to mention that there is a simple way to do hardware COS without opening the radio on Baofeng UV-5Rs. There's a DC bias in the speaker output that you can use to trigger a GPIO pin when the squelch is open. You can also see it used in this YouTube video.

I added a diode and resistor to my AIOC and then ran it to a GPIO pin on a Raspberry Pi. I imagine you could do something similar on the AIOC PCB and then return the COS status vi CM108 emulation (or some other way). I tried wiring it up on the schematic but got really stumped trying to fit anything onto that tiny little PCB. It's my first go in KiCad.

Anyway, this is what I was thinking:

I tried adding this to #17 but wasn't able to re-open the issue.

[skuep]

Hi, sorry for the late reply. That's an interesting solution that I might add in a future hardware revision. But I think it will only be limited to this one radio, correct?

[waydenie]

This is an interesting possibility, does the AIOC firmware already support hw COS on any of the input GPIO's? ( even if current devices would need to be modified with a board bodge? )

It might be nice for a future revision of the board and fw to include a pin with current limit/protection brought out to a pad for external COS options. Perhaps like shown in the schematic above , it could have a shorting pad to RADIO-SPK so that you can either connect it there to take advantage of a radio with AF DC bias, or leave it unshorted to connect your own external hw COS hardware.

[skuep]

Stay tuned for the next hardware revision.. It will be able to use either PTT pin as hardware COS 😁 Might be a nice way to easily hack in this feature as a side effect.. but I need to think about how to split the bias signal from the actual AF signal so it doesn't disturb the COS detection...

[rxt1077]

I'm not sure how it works on other radios (seems kinda hackish to have such a large DC bias, maybe it's just a Baofeng thing) and @waydenie's suggestion as to current protection is certainly warranted.

[W1BTR]

I've been working on the AIOB, and a big request I get is a hardware COS input and output pad. Is there a pin on the STM chip that is already ready for a hardware COS input?

[skuep]

There are long-standing future plans on 2 additional inputs on the STM32 that could be used for COS (eventually). Check out this branch: https://github.com/skuep/AIOC/tree/k1-aioc-rev1.1

For reference, here the schematic:

PB6 and PB7 are two inputs that are connected to the PTT1/2 pins on the AIOC board, so we get combined GPIOs. However in software, the inputs and outputs will be handled separately so that you can easily use PB6/PB7 as inputs for COS. They are also 5V capable btw. I suggest we could use the pin labeled PTT2-IN to default as COS input.

[W1BTR]

There are long-standing future plans on 2 additional inputs on the STM32 that could be used for COS (eventually). Check out this branch: https://github.com/skuep/AIOC/tree/k1-aioc-rev1.1

For reference, here the schematic:

PB6 and PB7 are two inputs that are connected to the PTT1/2 pins on the AIOC board, so we get combined GPIOs. However in software, the inputs and outputs will be handled separately so that you can easily use PB6/PB7 as inputs for COS. They are also 5V capable btw. I suggest we could use the pin labeled PTT2-IN to default as COS input.

Ah, that's where the split pad is. That's great! Ill have to compare the changes to make sure I can update the AIOB

[G1LRO]

Hi Simon, I'll give this thread a bump up.

I've now been making radio implementations using PB7 active low for hardware COS, so hopefully the code can be grafted into V1.3 (keeping the support for CM108 IDs etc.)

I'll encourage others in the maker community using the AIOC CPU to contribute to this thread also.