Serial port issues

nerdoftech · July 8, 2020, 2:03am

Hello, new to Mashtastic. I am trying to write some serial port communication and golang and seem to be running into a few issues.

The first issue I am seeing is that whenever I communicate to the serial port, the device screen then locks up and stays locked even after I disconnect the serial port. It seems the only way to fix it is to reset the device.

The second issue is that there are many settings that don’t not seem too write to the device. Some examples are the Wi-Fi settings and the user settings.

Here is the code I wrote:

github.com

nerdoftech/Meshtastic-go/blob/master/examples/config/config.go

package main

import (
	"time"

	"github.com/nerdoftech/Meshtastic-go/pkg/mesh"
	log "github.com/sirupsen/logrus"
)

// 32 bit key for aes 256
var psk = []byte{0xee, 0xd9, 0x50, 0xfd, 0xda, 0x4e, 0xc7, 0xea,
	0x3a, 0x89, 0xa3, 0x4c, 0xf5, 0xa1, 0x7f, 0xb2,
	0x68, 0x44, 0xb5, 0xb1, 0xc7, 0xf2, 0xeb, 0xaf,
	0xd7, 0x7d, 0xc9, 0x53, 0x70, 0x6c, 0x8c, 0x73}

func main() {
	log.SetLevel(log.DebugLevel)

	m, err := mesh.NewMesh("/dev/ttyUSB0", mesh.TRANSPORT_SERIAL)
	if err != nil {

This file has been truncated. show original

Thanks in advance.

geeksville · July 8, 2020, 3:23am

re: screen disabled while API is in use
That was by design, but others have asked to turn this ‘feature’ off as well. So probably it was a bad idea ;-). Would you mind putting in a bug for meshtastic-device and after 1.0 is finished we’ll (probably me ) fix this.

re: screen stays disabled even after you stop using the API
Internally we have EVENT_SERIAL_DISCONNECTED which is supposed to cause this but nothing is currently publishing that event. I’ll fix that at the same time I fix the other thing.

re: written changes are not accepted
can you elaborate on this? Are you saying you change something like ChannelSettings.Name but then if you disconnect and reconnect, you don’t see the changed value? If so that’s a bit puzzling. Perhaps you can try running “meshtastic --debug --setpref channel_settings.name test” and watch what the python tool sends across to compare?

nerdoftech · July 9, 2020, 12:03am

Thanks for getting back to me. I will file issues for the serial port as requested.

The issues with writing configs seem to be:

In radio_config->user_preferences the WiFi settings look look like they are not updating. I’m not well versed with C++ but does this mean the WiFi settings can not be changed yet:

github.com

meshtastic/Meshtastic-device/blob/c3f78292556afd6987771a51d3b3e08974e247ec/src/main.cpp#L155-L172


    strcpy(radioConfig.preferences.wifi_ssid, "geeksville");
    strcpy(radioConfig.preferences.wifi_password, "xxx");
    if (radioConfig.has_preferences) {
        const char *wifiName = radioConfig.preferences.wifi_ssid;

        if (*wifiName) {
            const char *wifiPsw = radioConfig.preferences.wifi_password;
            if (radioConfig.preferences.wifi_ap_mode) {
                // DEBUG_MSG("STARTING WIFI AP: ssid=%s, ok=%d\n", wifiName, WiFi.softAP(wifiName, wifiPsw));
            } else {
                // WiFi.mode(WIFI_MODE_STA);
                DEBUG_MSG("JOINING WIFI: ssid=%s\n", wifiName);
                // WiFi.begin(wifiName, wifiPsw);
            }
        }
    } else
        DEBUG_MSG("Not using WIFI\n");
}

As far as the user goes, I can’t tell if it is working because user can only be sent as a to-radio message, but you can’t view the current setting in a from radio message, if I’m reading the proto file correct.

geeksville · July 9, 2020, 12:09am

You can. It is a (poorly documented? ) requirement for using the API that the client start the flow by sending a start config message and then the device will send all the initial state a client needs - including the radio config.

For an example, try running “meshtastic --info --debug” and you’ll get to watch the initial packet exchange from the python client does.

You also might want to look over __init.py inside the portion api - I bet the classes you will want to make for your cool Go api will be similar.

geeksville · July 9, 2020, 12:14am

This might be useful for you. The serial API is basically identical (except one streams with extra framing and the other uses datagrams) the Bluetooth api. When the wifi code is enabled it will use the streaming API over TCP:

github.com

meshtastic/Meshtastic-device/blob/master/docs/software/bluetooth-api.md

# Bluetooth API

The Bluetooth API is design to have only a few characteristics and most polymorphism comes from the flexible set of Google Protocol Buffers which are sent over the wire. We use protocol buffers extensively both for the bluetooth API and for packets inside the mesh or when providing packets to other applications on the phone.

## A note on MTU sizes

This device will work with any MTU size, but it is highly recommended that you call your phone's "setMTU function to increase MTU to 512 bytes" as soon as you connect to a service. This will dramatically improve performance when reading/writing packets.

## MeshBluetoothService

This is the main bluetooth service for the device and provides the API your app should use to get information about the mesh, send packets or provision the radio.

For a reference implementation of a client that uses this service see [RadioInterfaceService](https://github.com/meshtastic/Meshtastic-Android/blob/master/app/src/main/java/com/geeksville/mesh/service/RadioInterfaceService.kt).

Typical flow when a phone connects to the device should be the following (if you want to watch this flow from the python app just run "meshtastic --debug --info" - the flow over BLE is identical):

- There are only three relevant endpoints (and they have built in BLE documentation - so use a BLE tool of your choice to watch them): FromRadio, FromNum (sends notifies when new data is available in FromRadio) and ToRadio
- SetMTU size to 512
- Write a ToRadio.startConfig protobuf to the "ToRadio" endpoint" - this tells the radio you are a new connection and you need the entire NodeDB sent down.
- Read repeatedly from the "FromRadio" endpoint. Each time you read you will get back a FromRadio protobuf (see Meshtatastic-protobuf). Keep reading from this endpoint until you get back and empty buffer.

This file has been truncated. show original

nerdoftech · July 9, 2020, 12:40am

The python API has been immensely helpful. I’ve been modeling the Go client after it. I have it send the want config id message first upon connection to the serial port then the reply asynchronously stores the config to a property of the mesh object.

I was tried to reply with a link to the code on github showing this, but now for some reason my posts are being flagged as spam.

nerdoftech · July 9, 2020, 12:44am

Looks the system restored posting. Here are the github links to the relevant sections:

github.com

nerdoftech/Meshtastic-go/blob/master/pkg/mesh/mesh.go#L109-L119


func (m *Mesh) getRadioConfig() error {
	rand.Seed(time.Now().UnixNano())
	rn := rand.Uint32()
	msg := &message.ToRadio{
		Variant: &message.ToRadio_WantConfigId{
			WantConfigId: rn,
		},
	}
	log.WithField("config_id", rn).Debug("sending WantConfig to radio")
	return m.sendToRadio(msg)
}

The reply asynchronously handled and puts the config as a property to the mesh object:

github.com

nerdoftech/Meshtastic-go/blob/master/pkg/mesh/mesh.go#L152-L154


		case *message.FromRadio_Radio:
			log.WithField("radio", msg.GetRadio()).Debug("got radio config")
			m.radioConfig = msg.GetRadio()

nerdoftech · July 9, 2020, 1:02am

Ah, now I see the part about where to get the user info:

https://github.com/meshtastic/Meshtastic-protobufs/blob/master/mesh.proto#L654-L657

So I can set the name and when I get the list of nodes again, it changes:

my_node="my_node_num:3045257816 has_gps:true num_channels:13 region:"1.0-US" hw_model:"tbeam" firmware_version:"0.7.10" packet_id_bits:32 current_packet_id:1613480412 node_num_bits:32 message_timeout_msec:300000 min_app_version:172

node=“num:3045257816 user:{id:"4321" long_name:"lora2" short_name:"L2" macaddr:"\x8c\xaa\xb5\x82\xf2X"} position:{latitude_i:xxx longitude_i:-xxx altitude:xxx battery_level:100 time:1594256178}”

However, when I reboot the device it reverts the name back to a previous one:

node=“num:3045257816 user:{id:"!8caab582f258" long_name:"Lora3" short_name:"L" macaddr:"\x8c\xaa\xb5\x82\xf2X"} position:{latitude_i:xxx longitude_i:-xxx altitude:xxx battery_level:100 time:1594256177}”

geeksville · July 9, 2020, 1:55am

yeah - changes to the node db/config are only written to flash when the device enters deep sleep (i.e. we weren’t planning on users pressing reset ever). If you just press the reset button the changes will be lost. Hmm - we should probably add a disconnect message an API client can send to indicate it is done talking to the the device (related to your original post) and when that message comes in we should go ahead and write to flash just in case.

Topic		Replies	Views
Meshtastic --info Version 1.2 problem Python API	6	739	March 13, 2021
Dead(almost) ttgo v1.1	13	1101	May 16, 2022
Serial Connection Issue	2	922	June 11, 2022
Serial Connection Error after 1.3 update Support	3	592	September 15, 2023
Serial port on RAK4631 gone after loading dev build Development	7	980	August 11, 2021

Serial port issues

Related topics