Intermittent Tx and Rx on 50Mhz with RS-918

[rogerclarkmelbourne]

Firmware

Your firmware version: 28th Aug v2.11.67 Your bootloader version: 5.0.4

Hardware

Chinese made RS-918, brand new.

Describe the issue:

50Mhz Tx initially works after powering on the radio. However within 1 minute if I try to Tx again, there is no output on 50Mhz.

If I turn the radio off and immediately on again, sometimes the radio transmits again on 50MHz.

Also, initially after powering on the radio, it appears to receive on 50Mhz, however over a period of about 1m, the RSSI slowly drops, and the radio does not receive any more on 50MHz.

While the RSSI is still high (I have local QRM on 50Mhz from solar inverters), the Tx seems to work. However as soon as the Rx stops working the Tx also seems to stop working.

One additional piece of information, the display next to the TCXO mostly shows the word "RANGE!" I looked in the source code and this would indicate that the radio is not able to read the temperature sensor. I have not opened the radio but I presume they have not fitted the sensor as a cost saving.

However, I presume the firmware thinks the sensor is fitted, otherwise I presume there would be a different message.

[sp9bsl]

First of all, mcHF is not intended to be used on 6m unless you change the LPF/BPF filters, please look for the filter characteristics for mcHF on the web. I'm speaking of original design - you have chinese clone with chinese SI570 which is also uncertain. What I see based on your description - the SI570 stops working for 6m after a while...

73 Slawek

[df8oe]

6m is not within the supported range of hardware. It is "experimental" because of many hardware issues (no filters, speed of mixers too low, PLL may not lock e.g.) As you can see in the description of your rig the supported range is up to 30MHz.

vy 73 Andreas

[db4ple]

Well, the officially supported range for the Si570 is 160 Mhz (which would allow tuning up to 40 Mhz. In order to achieve 50 Mhz we go well beyond the offical spec to about 200 Mhz. Experiments have shown that the Si570 is able to go to roughly 220 Mhz. But it seems to me it produces too much heat if outside the range and then stops working. Would explain all what you experienced except for one thing: A normal UHSDR firmware should not transmit at all at 6m meters. We have a check if the TX freq is within the supported range: https://github.com/df8oe/UHSDR/blob/c32698aab9bcc14593a9317890f13aaa0a22117b/mchf-eclipse/drivers/ui/radio_management.c#L735-L744 and our frequency range for the PA is defined like this:

https://github.com/df8oe/UHSDR/blob/c32698aab9bcc14593a9317890f13aaa0a22117b/mchf-eclipse/drivers/ui/radio_management.c#L268-L275

So the limit would be 32 Mhz. That is for obvious reason as mentioned by @sp9bsl a very good idea, as transmit power will be mostly dumped into the BPF / LPF.

Side note to the developers: This makes me think if we should by default limit the supported RX bands by the union of the BPF / LPF ranges and the oscillators capabilities. I.e. for the mcHF RF board this would let us stop at 32 Mhz. And we could have a "debug" option to enable reception over the full LO range if this is larger than the BPF. For transmit we have to set the limit to the BPF / LPF ranges of the hardware in any case in order to prevent bad things happening.

[rogerclarkmelbourne]

Interesting.

I downloaded the latest pre-compiled latest binary, via https://df8oe.github.io/UHSDR/

The display on the radio indicates that its transmitting 8W on 50Mhz and I attached a power meter to the output which also showed it was producing power, but lower than the display indicated.

However I didn't check what frequency it was actually transmitting on.

I think by default the firmware should not allow operation beyond the max spec freq of the Si570

I'm not sure if its worthwhile even adding a debug option to allow this, as anyone who really wants to push their hardware could just recompile from sources to remove the frequency limit.

[sp9bsl]

@roger: db4ple mentioned about RX option in debug menu, the tx is limited by pa_info_t (at least it should be) - I agree to limit the RX by default.

BTW pa_info_t: I think we should point to mchf structure in ts, hardcoding it in radio_management disables the posibility to change to other hardware. I also think about a structure which defines the particular RF hardware and is pointed by ts structure.

[db4ple]

@sp9bsl : Yes, of course, to convert this to a dynamic mapping is planned. It is necessary to have this once we have more than one RF hardware and have a way to identify which one is attached to the UI. That's why I created this structure in the first place.

I will have to check why the TX limit is not enforced as it should

[db4ple]

See pr #1809 . This will disable TX at 6m as it is clearly out of range of our hardware.

[rogerclarkmelbourne]

This is really off topic. But I wonder why the hardware design didn't use a Si5351 fed by an external TCXO.

[db4ple]

Well, the RS 928 does just that, save for the TCXO I'd venture to say. Just after we integrated support for the Si5351 in the firmware. Unfortunately we don't get a share of the savings the manufacturer makes...

In fact the Si5351 would have been an even more clever choice as it can generate the 90 degree phase shifted signal for a wide range of frequencies without need for a Johnson counter... But as you wrote, off topic.

On the topic: Have you been able to see the temperature rise above 100°C?

[rogerclarkmelbourne]

@db4ple

I'm not sure what you mean about the 100°C. Currently my radio is just displaying the word "Range!" instead of the temperature, but I have not opened the box to see whether the temperature sensor is missing.

Re: Si5351 Perhaps someone could make a retrofit board with a 25MHz TCXO and the Si5351. It would probably be small enough to install inside the normal case

[rogerclarkmelbourne]

@db4ple

I've disassembled my RS-918 and the boards are all fully populated, including the temperature sensor IC. (There is even the older for the battery backup button cell !)

So at the moment I don't know why the temperature is showing as "RANGE!"

I looked in the code and I found that if the MCP9801 is not present, then there should be a message on the Startup screen, but I checked and the startup is normal. Hence firmware thinks the sensor is present.

So its mystery why the temperature is "RANGE!".

Perhaps I will have to raise this as a separate issue.

[sp9bsl]

Hi Roger, I'll break my rule: do not support the clones, look to the mysterious code here:

https://github.com/df8oe/UHSDR/blob/4488defed8e78784a0e74f4e42e969c8a5c61275/mchf-eclipse/drivers/ui/ui_driver.c#L5141

If you are able to compile the code, probably you can debug too, just check what happened...

[rogerclarkmelbourne]

I have recompiled the code. As I made changes to the RIT step size.

I know where the code is that displays RANGE! and it looks like the code thinks the MCP9801 is being detected, because in

Because

if(!Si5351a_IsPresent() && RadioManagement_TcxoIsEnabled())
{
    UiDriver_StartupScreen_LogIfProblem(lo.sensor_present == false, "MCP9801 Temp Sensor NOT Detected!");
}

Should be displaying "MCP9801 Temp Sensor NOT Detected!" but its not.

I have a STLink (several of them), and also a JLink Edu and several other debuggers e.g. BlackMagic Probe, but I normally develop on the PC, and don't have a Linux box configured to use them.

I considered trying to porting the Eclipse project file to "System Workbench for STM32" or Atollic "TrueStudio" which is now owned by STM, but I think the least work will probably be to try to get OpenOCD working on my Linux machine.

BTW. I also tried connecting the USB DFU port to my W7 PC but W7 does not seem to support the composite USB device, which I assume contains a CDCACM device which perhaps I can use to write debug message, so and then just reload via memory stick, which would be a slow way to develop but not impossible ;-)

[rogerclarkmelbourne]

BTW. I should have mentioned, I've disassembled the radio and it seems to be an exact copy of the MCHF including all the silk screen text.

The MCP9801 is present on the PCB

[sp9bsl]

So, you are the one who can bring some light on this case, noone of the developers have a clone...

Regarding the build machine, I use W7, W8.1 and OpenOCD debug via STlink with no problems. The development setup is clearly described in our wiki.

BTW True Studio is obsolete (unfortunately) - see their web site.

[db4ple]

Hi there, setting up GNU MCU Eclipse on Windows (the tool chain I use) is quite simple if you follow the instructions. Loading the project there should give you a working debugging environment in a couple of minutes depending on your download and machine speed.

We don't support any other IDE environment at the moment.

[db4ple]

In any case, it looks like a hardware issue to me. The only thing I can think of on the software-side is the I2C speed, which may be an issue. Please check this. In any case, this part of the firmware has been working reliably for many users over years. Which does not mean there is no software issue but it is rather unlikely. I would make the software print the value regardless of the range so that you can see the temperature value.

[rogerclarkmelbourne]

Thanks

I'll need to add some debugging to investigate why its not working.

[S52CQ]

Hi Roger,

it's a bit off topic but anyhow: can you please explain how your output stage can deliver 8W at 50 MHz. My mcHF delivers only 1W at 28 MHz and close to zero at 50 MHz. I realize that you're using mcHF clone - can you please send to my email ( stik (at) svet-el.si ) a photo of your output stage?

73 de S52CQ, Jure

Interesting.

I downloaded the latest pre-compiled latest binary, via https://df8oe.github.io/UHSDR/

The display on the radio indicates that its transmitting 8W on 50Mhz and I attached a power meter to the output which also showed it was producing power, but lower than the display indicated.

[df8oe]

There are many RS918 out in the wilderness that do not have populated LPFs at all. There is a fat wire from the PA output transformer directly to the antenna jack. Maybe this is the reason :)

vy 73 Andreas

[S52CQ]

Hi Andreas, that could be one reason :)

I hope that Roger will share a photo of output stage of his TRX.

73s de S52CQ, Jure

[rogerclarkmelbourne]

I don't have photos of the radio, but I did make a video

https://www.youtube.com/watch?v=P3_kPa_HagY

[S52CQ]

Thanks Roger for the video. It seems that I will have to open my mcHF and do something about RF on higher bands. 73s de S52CQ, Jure

[rogerclarkmelbourne]

As there anything specific you need a detailed photo of.

I may have taken a photo, but I did not take close up photos of everything

[S52CQ]

Roger, if you can please take a photo of small driving transformer and area around it. 73s de S52CQ, Jure

[AngelSerra]

I doubt that the rd16hhf1 will work in the 6M 50MHz band according to the manufacturer, they only work up to 30Mhz, to make it work in 50Mhz it would be necessary to change the driver part and change the rd16hhf1 for others that work in 6m.

[Radiohr]

Well, the RS 928 does just that, save for the TCXO I'd venture to say. Just after we integrated support for the Si5351 in the firmware. Unfortunately we don't get a share of the savings the manufacturer makes...

In fact the Si5351 would have been an even more clever choice as it can generate the 90 degree phase shifted signal for a wide range of frequencies without need for a Johnson counter... But as you wrote, off topic.

On the topic: Have you been able to see the temperature rise above 100°C?

When i feed mchf with external si5351 its waterfall doesn't move...does any firmware got the support if i attach si5351 sda scl and cut off si570