We want to use the HC-12 in a small educational satellite. To do this we need to set it to Tx/Rx on 437.1 MHz. How can we edit the firmware to do this?

 

We want to use the HC-12 in a small educational satellite. To do this we need to set it to Tx/Rx on 437.1 MHz. How can we edit the firmware to do this?

The HC-12 has channels that are spaced 400 kHz apart. 437.1 MHz does not fall on a channel boundary. In order to make this happen you are going to have to take a dive into the guts of the application to see if the hardware will support what you want to do. I don't know enough about the internals to gauge your chances of success.

 

The HC-12 has channels that are spaced 400 kHz apart. 437.1 MHz does not fall on a channel boundary. In order to make this happen you are going to have to take a dive into the guts of the application to see if the hardware will support what you want to do. I don't know enough about the internals to gauge your chances of success.

Thank you PapaBravo, for checking in. I agree 437.1 MHz does not fall on an allocated channel. I believe that the channel allocation is an aspect of the way the manufacturer chose to write the HC-12 firmware that is installed on the general purpose STM8 microcontroller. I believe that the Si4463 radio IC is not limited to these channels, but rather it can transmit on whatever frequency the STM8 commands it to use. If that is correct then by (slightly I hope!) reprogramming the firmware loaded on the STM8, we can put the Tx on the frequency that we want. But I acknowledge that I may be wrong! Hope someone can set me straight on that.

 

Your assumption might be valid if the hardware supports such a change. From the available information it is not at all clear that it will. Maybe someone who is familiar with the device can opine on the flexibility and/or the difficulty of doing what you want. Do you know for a fact that the firmware can be updated?

 

The STM8 processor firmware only supports a limited set of AT commands specifically for use as a low-speed modem on the recognised 437MHz 400kHz channels. To acheive your required frequency will require new firmware programming into the STM8. If your requirements are straightforward this may not be as difficult as it seems as the Arduino IDE and Core are available for the STM8. You should peruse the Si4463 datasheet & user manual to see the various registers to be configured for your frequency.

What other functionality would you need? Data rate changes, power output, sleep mode, or.... ?

 

Hi Irving, thank you for these observations.

Right now we think that if we can just shift the frequency to 437.1 MHz and leave the rest of the current functionality in place, that we would have the performance we want to achieve.

On that, we hope we are close. We think we have the command figured out, we are working on what value to use. We will report more, later.

 

Hi Irving, thank you for these observations.

Right now we think that if we can just shift the frequency to 437.1 MHz and leave the rest of the current functionality in place, that we would have the performance we want to achieve.

On that, we hope we are close. We think we have the command figured out, we are working on what value to use. We will report more, later.

Hmmm, not sure what command that would be... the AT command set supported by the STM8 MCU firmware doesn't appear to have any provision for adjusting the Si4463 frequency generation registers and these are preset for 433.4MHz base and 400kHz channels. The only AT command is to set the channel number as 1 - 127, the nearest being 437.0MHz on channel 10.

 

Hmmm, not sure what command that would be... the AT command set supported by the STM8 MCU firmware doesn't appear to have any provision for adjusting the Si4463 frequency generation registers and these are preset for 433.4MHz base and 400kHz channels. The only AT command is to set the channel number as 1 - 127, the nearest being 437.0MHz on channel 10.

It was my understanding that the TS wanted to modify the firmware of the device. This is a different proposition than writing a sketch in the Arduino IDE. Assuming this was possible what would the TS propose as the starting point. Dump the NV memory, disassemble the firmware, and reverse engineer a source file. Then there is the problem of deciding if the hardware can support other frequency selections. It will be a job of work.

ETA: I'd be willing to bet a modest sum that the source files and build environment for the firmware are not readily and publicly available. Of course I could be wrong which would simplify the problem considerably.

ETA2: Modifying the firmware for a device that has received regulatory approval may open up a different can of worms.

 

It was my understanding that the TS wanted to modify the firmware of the device. This is a different proposition than writing a sketch in the Arduino IDE. Assuming this was possible what would the TS propose as the starting point. Dump the NV memory, disassemble the firmware, and reverse engineer a source file. Then there is the problem of deciding if the hardware can support other frequency selections. It will be a job of work.

ETA: I'd be willing to bet a modest sum that the source files and build environment for the firmware are not readily and publicly available. Of course I could be wrong which would simplify the problem considerably.

ETA2: Modifying the firmware for a device that has received regulatory approval may open up a different can of worms.

Working on the assumption that the firmware wouldn't be accessible, I was suggesting that a simplified application with just fixed frequency setting and UART functionality would be relatively easy to provide with common tools. Setting a frequency of 437.1MHz involves just 4 or 5 registers on the Si4463 - everything is documented nicely in the data sheet - and we know the hardware is good for it as the desired frequency is only 100kHz off a standard channel. The Arduino Core provides all the UART functionality; there are number of 3rd party 'programmer' clips that can connect to the STM8 processor. Lifting the existing MCU and replacing with a fresh one isn't so hard.

Of course, if the firmware was available, or could be easily extracted & decompiled, than that would be the preferred route, but I would take a bet on that not being as simple as it sounds.

While regulatory approval might be an issue, I'll take a bet the intended use has no such issues as EMI/EMC testing against other elements of the satellite and launch vehicle will be done as standard - there are many examples of amateur/student satellites built down to a budget that clearly didn't go through 'regulatory approval' testing in the conventional way - it would be cost prohibitive.

 

Hmmm, not sure what command that would be... the AT command set supported by the STM8 MCU firmware doesn't appear to have any provision for adjusting the Si4463 frequency generation registers and these are preset for 433.4MHz base and 400kHz channels. The only AT command is to set the channel number as 1 - 127, the nearest being 437.0MHz on channel 10.

Hi Irving,

I agree, some work involved here, certainly! My hope is that someone out there has done at least some of the following and is willing to share their experience.

Steps to changing HC-12 to Tx/Rx on 437.1 MHz, repeating back some of what has been said by PapaBravo and you.

1. Read existing firmware from non volatile memory, e.g., copy it to an environment where you can read and edit it. What tool / connection is used for that?
Step 1 can be broken down as follows:
Attain a general understanding of the STM8 microcontroller - how it is programmed, and if how to pull firmware off of it;
and/or
Obtain guidance from someone who has specifically pulled firmware off the STM8 as applied to the HC-12;
and/or
Obtain the firmware that is on our version of HC-12.

2. Disassemble firmware code. Again, what tool?

3. Edit the assembler level code. What editor tool? What commands need to be sent by the STM8 firmware to the Si4463 to make it Tx on 437.1 MHz?

4. Assemble the code. What assembler?

5. Write the code into the microcontroller non volatile memory. What software and hardware are needed to do that?

This will IMO require the kindness of those who have done some part of this, sharing their experience.

 

The STM8 series feature ICP (In-circuit programming) as documented here. Its likely, but not guaranteed, that this is available on the boards - so firmware can be updated on pre-manufactured boards. I've not hacked an STM8 but I've done it on other MCUs. The protocols and hardware to do so are relatively simple and I'm sure its been done already, rather than purchasing official programmer hardware (a quick search of github suggests there are several open-source options). The software development tools are freely available from STM, see here. Not sure if that includes a disassembler though.

I don't have an HC-12 here at the moment, they're all in use elsewhere. There are several versions of HC-12, some with Si4438 and some with Si4463 RF ICs. Which do you have? I think all the ones I had were the earlier device. Also some feature an STM8 in a QFN20 package, and some a TSSOP20 package which may have a bearing on physical connectivity. Finally of course, if the code protection fuses have been blown you're out of luck.

There is another option - I've seen Si4463 boards without the STM8 processor, just an I2C interface, which you could marry with an MCU of your own choosing...

[edit] I've since read that the HC-12 firmware is protected... while there are ways to overcome this, they aren't simple/easy to implement.

 

The STM8 series feature ICP (In-circuit programming) as documented here. Its likely, but not guaranteed, that this is available on the boards - so firmware can be updated on pre-manufactured boards. I've not hacked an STM8 but I've done it on other MCUs. The protocols and hardware to do so are relatively simple and I'm sure its been done already, rather than purchasing official programmer hardware (a quick search of github suggests there are several open-source options). The software development tools are freely available from STM, see here. Not sure if that includes a disassembler though.

I don't have an HC-12 here at the moment, they're all in use elsewhere. There are several versions of HC-12, some with Si4438 and some with Si4463 RF ICs. Which do you have? I think all the ones I had were the earlier device. Also some feature an STM8 in a QFN20 package, and some a TSSOP20 package which may have a bearing on physical connectivity. Finally of course, if the code protection fuses have been blown you're out of luck.

There is another option - I've seen Si4463 boards without the STM8 processor, just an I2C interface, which you could marry with an MCU of your own choosing...

[edit] I've since read that the HC-12 firmware is protected... while there are ways to overcome this, they aren't simple/easy to implement.

Thank you all for your insights. We are redirecting our effort to a more limited objective. We will limit our operation to the already established frequency channels.

In an earlier post it was mentioned that HC-12s only like to talk to other HC-12s, is that right? Can anyone help me understand what the limitation is that would prevent using a typical UHF transceiver to either receive data from, or transmit data to, the HC-12? Any insight on this would be greatly appreciated.

 

Thank you all for your insights. We are redirecting our effort to a more limited objective. We will limit our operation to the already established frequency channels.

In an earlier post it was mentioned that HC-12s only like to talk to other HC-12s, is that right? Can anyone help me understand what the limitation is that would prevent using a typical UHF transceiver to either receive data from, or transmit data to, the HC-12? Any insight on this would be greatly appreciated.

As I understand it, the internal communication between the HC-12s has a degree of retry and uses a fixed internal data rate depending on distance/signal strength.

 

Thank you all for your insights. We are redirecting our effort to a more limited objective. We will limit our operation to the already established frequency channels.

In an earlier post it was mentioned that HC-12s only like to talk to other HC-12s, is that right? Can anyone help me understand what the limitation is that would prevent using a typical UHF transceiver to either receive data from, or transmit data to, the HC-12? Any insight on this would be greatly appreciated.

I assume you're building some sort of RF beacon for people on the ground to detect your bird as I've seen 437.1MHz used in several space probes for the purpose. Is there no other source for a low-cost transmitter for this specific use?

 

Can you identify the frequency of the crystal?
Maybe that could be pulled enough to get the 100k offset you need?

 

Can you identify the frequency of the crystal?
Maybe that could be pulled enough to get the 100k offset you need?

JohnSan and all: we abandoned the attempt to reconfigure the HC-12 frequency channels, and found a path to work with a frequency that it already supports.

Our efforts now have focused on unpacking / understanding the HC-12 modulation and packet structure so that we can send to and receive from the HC-12 with other radios that are not HC-12s. We think that we have that figured out. Anyone else working on this?