[Bug]: Only one way long messages on powerful RA-01S-P (RA-01SH-P)

[iuvi7]

Category

Hardware Compatibility

Hardware

DIY

Is this bug report about any UI component firmware like InkHUD or Meshtatic UI (MUI)?

• Meshtastic UI aka MUI colorTFT
• InkHUD ePaper
• OLED slide UI on any display

Firmware Version

v.2.7.3.cf574c7

Description

Hi!

I created two devices and set them up on LONG_FAST preset. Device one (with RA-01S-P module, 29dB) can send only ~97 symbols (1 meter distance) to device number two. At the same time and distance, it can receive 200 symbols from device number two (Wich is HT-RA62, 22dB)

Device one:

• Esp32c3 + RA-01S-P powered from 3.3v placed on PCB (schematics could be found here - https://github.com/mrekin/MeshtasticCustomBoards/tree/main/firmware/variants/esp32c3/diy/diy_c3_ra-01s-p) 5dB max (firmware "installed c3-ra-01s-p" https://mrekin.duckdns.org/flasher/)

Device two:

• NRF52840 + HT-RA62 powered from 5v (Directly by USB-C) placed on PCB (FakeTec v3, schematics could be found here - https://github.com/gargomoma/fakeTec_pcb) 22dB max

So, sending long messages ain't works well for RA-01S-P, but receiving - not a problem. It is quite strange

If i change both nodes to LONG_MODERATE it works fine for a both directions (wich is kinda solves problem, but works bit slowly and can not afford to be a part of main LONG_FAST mesh in many city's\outdoors nodes to use hops)

Thanks

Relevant log output

[fifieldt]

Which frequency band are you using?

[ISVLabs2]

Module RA-01S-P is 400/500 mhz only. For 869/915 band there is RA-01SH-P.

[iuvi7]

Which frequency band are you using?

Malaysia 433 preset was used. Also tryed to turn on licensed radio so no limits on power

[sbeardPA]

I can confirm the same behavior has been seen on Faketec V4 and V5 DIY builds with the RA-01SH-P chips. Receive works and messages shorter than 20 bytes send on Long Fast . We are in the US and on the default frequency (20). Moving to Long Moderate allows for messages up to the full 200 bytes. Here is a serial console capture of the attempt and failure of the message. The "Alloc an err=5" is the moment the max retries are met. RA-01SH and HT-RA62 chips don't experience this issue
RA-01SH-P send error.pdf

[GUVWAF]

Both the RA-01SH-P and HT-RA62 do not have a TCXO (temperature-compensated crystal oscillator). When transmitting at high power, it might be the chip heats up and that causes the oscillator to drift away, which gets worse for long packets. If you look at the receiver logs, you might see "Packet RX (noise?)", indicating a decoding error.

See also: https://youtu.be/PND1GlMSrEM

[sbeardPA]

Dead on @GUVWAF This appears to be an issue from the lack of TXCO in this chip like you mentioned coupled with the high output. Long _fast is 3 times the bit rate of Long_moderate so the transmit requires more power. If you put a board in the freezer for 30 minutes you can transmit long messages at full power on long_fast successfully. Just confirmed it with 2 Faketec V4 boards

[iuvi7]

HT-RA62 actually now days do have TCXO (they fixed oscillators after many complains of users after bad first batch of production)
Don't know if RA-01S-P too, so... It's double weird working only one way too

@GUVWAF @sbeardPA Also, we tryed drop down transmission power to a minimum, but result just a liiiitle bit better on a few symbols

[sbeardPA]

Correct, the HT-RA62 has the TXCO while the RA-01SH and RA-01SH-P do not. Surprisingly, we have not experienced any issue with RA-01SH chips and we have quite a few in use in our area. Just the -P chips are causing problems.

[iuvi7]

@sbeardPA @GUVWAF

Alright, if issue is in Hardware, what is in your opinion can be done to make those chips to work on Long_fast correctly?

I mean, question is - if HT-RA62 have TCXO, with it - it can only send, but not recive from RA-01S-P as my experiment shows... So, wouldn't it be the same if they add TCXO to RA's modules? Or they need to find and add TCXO's that are more efficient on higher power transmission rate?

P.S. I have email of the Ai_thinker producer. I think if many complains sended to them maybe they could change their minds on TCXO (or other ways to fix a problem) - if someone could, that would be awesome

[GUVWAF]

The issue on the transmit side. When the oscillator drifts away, the transmission gets garbled if it's long enough. There's likely no device that can receive long packets from the RA-01-S-P without TCXO.

[sbeardPA]

After doing the freezer test I’m convinced that the lack of TXCO is the issue. I guess the lower output of the RA-01SH 22db radio must keep the heat low enough that it isn’t an issue but I still have concern it will become an issue in high traffic nodes. The HT-RA62 has been rock solid. I am going to email AI Thinker and let them know of the issue and encourage them to add a TXCO in future releases. I agree that there is nothing firmware related that is going to correct this issue. Thanks all for thinking through this .

…

On Sun, Jul 27, 2025 at 5:51 AM GUVWAF ***@***.***> wrote: The issue on the transmit side. When the oscillator drifts away, the transmission gets garbled if it's long enough. There's likely no device that can receive long packets from the RA-01-S-P without TCXO. — Reply to this email directly, view it on GitHub <#7430 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BURXUI24NC2YLFX7MFGHPCL3KSOIHAVCNFSM6AAAAACCGJ7JY2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGOJQGA3TQMQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[iuvi7]

Emails:

Engineer (if i'm right) [email protected]
Main overseas supervisor [email protected] +86-15817421307 （whatsapp/wechat)

P.S. Maybe those Lora modules can give idea what can be done too? They works on high power, did not jumped into datasheets tho

Praying for best! :)

E22-400M30S (https://www.cdebyte.com/products/E22-400M30S) (410–493 MHz at 30 dBm)
E22-400M33S (https://www.cdebyte.com/products/E22-400M33S) (410–493 MHz at 33 dBm)
E22-900M30S (https://www.cdebyte.com/products/E22-900M30S) (850–930 MHz at 30 dBm)
E22-900M33S (https://www.cdebyte.com/products/E22-900M33S) (850–930 MHz at 33 dBm)

[iuvi7]

@GUVWAF @sbeardPA @ISVLabs2 Thanks for you answers

Sad news received today from Ai_thinker company. Now they saw issue with TCXO, but said: those modules made for passive purposes, and they would not change them ...

Only way to get it done (and also change power to 5v to get even 31dB!!!) is and individual order, but i don't think i can find community people to crowdfund it ("This customize module would need MOQ 5kpcs.")

They could got get sold if order them, i can put some money in, but there is big unbalance yet... Do you think it reasonable as for now? Or maybe there's a way to find factory wich could make "similar" but with tcxo?

[sbeardPA]

That’s disappointing but not surprising. I’ll just stay away from their chips. For 22db applications I’ll use the HT-RA62 and for higher power I’ll use the Ebyte E series on a different board

…

On Wed, Jul 30, 2025 at 1:21 PM iuvi7 ***@***.***> wrote: @GUVWAF <https://github.com/GUVWAF> @sbeardPA <https://github.com/sbeardPA> @ISVLabs2 <https://github.com/ISVLabs2> Thanks for you answers Sad news received today from Ai_thinker company. Sadly they saw issue with TCXO but said those modules made for passive purposes, and they would not change them ... Only way to get it done (and also change power to 5v to get even 31dB!!!) is and individual order, but i don't think i can find community people to crowdfund it ("This customize module would need MOQ *5kpcs*.") They could got get sold if order them, i can put some money in, but there is big unbalance yet... Do you think it reasonable as for now? Or maybe there's a way to find factory wich could make "similar" but with tcxo? — Reply to this email directly, view it on GitHub <#7430 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BURXUI7VSWF4FBYU3CQC3PT3LD5IJAVCNFSM6AAAAACCGJ7JY2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGOJTG4YDCMA> . You are receiving this because you were mentioned.Message ID: ***@***.***>