Meshtastic 1.3.19 - June 16 Public Preview

This fixes the “Critical Error 7” issue.

My TBeam talks to me over serial port with 115200 baud
—edit—
And my tlora32 v2-1.6.1 does the same way

That’s a change we made to address connection issues with some devices. It’ll mean better general stability while doing firmware updates, debugging and generally connecting over serial.

Äh, reading helps - especially release-info

I’ve switched tack and I’m using two Android devices now. The Meshtastic app on my second Android device doesn’t get a Channel Name populated. It’s just blank and cannot be edited/ scanned/ reset, etc.

I’ve tried deleting and reinstalling the app/ forgetting the bluetooth devices, etc but there’s no way to set the channel name as far as I can see.

Can anyone advise me on that please?


It does seems to be very hit and miss as to whether the channel name is populated or not. I’ve deleted and repaired the TBeam over Bluetooth probably 25 times now and only got the channel name populated a couple of times.

It seems to hang on ‘Pairing successful, starting service’ quite often too.

Unpaired/ forgot the device in the Bluetooth screen and added it in again and the channel is set correctly this time. Everything looks good. Both devices are showing on the map on both Android devices, the stats of the other device is showing on both, etc.

However, messages don’t appear to send. They don’t fail either. Debug Panel is blank on both Android devices.

Edit: they do eventually fail.

thanks for all the feedback. android release 1.3.19 is out.

looks like the back stack / back button is clearing memory and losing connection. for now, avoid the back button on root and use home button instead. or click “None (disable)” and restart the connection.

Thanks. I just gave the new Android app a try. (I uninstalled the old one, forgot both Tbeams in the Bluetooth screen and then installed the APK fresh).

The app seemed to hang at ‘Pairing completed, starting service’. My phone screen went off, I then bought it back to life and it was showing ‘Connected to Tbeam 1.3.19.3c6a2f7’. The Channel Name is blank though, and I can’t edit it or scan or reset or any of those options.

I haven’t pressed back at all on my Android device.

On my second Android device it has hung at ‘Pairing completed, starting service’. I have kept the screen alive for about 5 minutes now, but nothing has changed.

1 Like

a device reset should take care of that.

My second Android device eventually went to sleep, and after I brought it back to life it was showing ‘Connected to radio (Tbeam 1.3.19.3c6a2f7)’.

Same thing though, the Channel Name is blank and cannot be changed of scanned or reset. And therefore, in the Messages tab it’s called ‘Channel Name’ rather that ‘Long-Fast-I’ or whatever.

I can actually send a message from Tbeam 1 to 2, but not 2 to 1. The message appears on the Tbeam screen, but not on the Android device.

Tbeam 1 then rebooted randomly and popped up with the pairing screen. Now the app is stuck at ‘Pairing completed, starting service’ again.

You’re right. Resetting the Tbeam made the Channel Name populated. They’re both now on #LongFast-I.

The same is true with the messages though. Sending a message from 1 to 2 makes it appear on the Tbeam screen only (not in the app).

Sending a message from TBeam 2 to 1 does nothing at all.

1 Like

I have looked at the Region info in Radiointerface.cpp, for EU you have:

RDEF(EU868, 869.4f, 869.65f, 10, 0, 16, false, false),

But as far as I understand for Switzerland from the official OFCOM site:
https://www.ofcomnet.ch/api/rir/1008/09
we are allowed up to 500mW erp with a 10% duty cycle on the 869.400 - 869.650 MHz band. Did I misunderstand something? Or could we have a Swiss Region definition that allows this in one of the upcoming updates? And no, I don’t want to fry my SX1262 with a too high setting.

Your post prompted me to have a read of Ofcom UK’s document IR2030 (page 15-17): https://www.ofcom.org.uk/__data/assets/pdf_file/0028/84970/ir-2030.pdf

IR2030/1/19 allows 869.40-869.65 MHz up to 500mW e.r.p up to 10% duty cycle too.

Can we use this band for Meshtastic?

Isn’t it in use when one chooses EU868 as region/band ? At least my AirSpy/SDRSharp can see traffic around 869,40 MHz and it is coming from my setup. Right now the 1.3.19 does not apply 10% rule as nodes send one packet/30s with length of 0.8s.

That’s interesting.

Clearly RDEF(EU868, 869.4f, 869.65f, 10, 0, 16, false, false), means it will operate between 869.4 MHz and 869.65 MHz. Cool.

The next question is the power level. 10 or 16 might be specifying the level. 10dBm (10mw) or 16dBm (40mW) seems low if we’re allowed to transmit at up to 500mW. Is it possible to increase the power?

Max power depends after all what you have as chipset i.e. 1276 or 1262 in your node. There are several threads open here with different suggestions.

Thanks. I found this thread from 2020 which says a setTxPower setting of zero sets the power to the maximum the chipset can handle: Question about setTxPower

It seems like that is a maximum of about 22dBm(158mW) - for an SX1262 device (eg a TBeam).

1 Like

the 10 means 10% duty cycle, the 16 is the max dBm. The power limit comes from the ETSI specification for that band.

1 Like

Does 1.3.19 already enforce 10 % duty cycle ? I observe that node sends once in 30s a datapacket taking around 0.8s. If it does not do any pauses in sending then we exceed the 10% duty cycle. I recall LMIC having a mechanism for enforcing duty cycle.

with meshtastic packets you can not really interrupt sending, so it will pause after the burst. airtime is calculated in a sliding window. But i am sure @mc-hamster can explain it better than me. Duty cycle will be enforced on that metric, but i think it’s not in the source yet.