I’ve been at this for days. The docs arent clear in terms of development in a number of places. I may be being dense but I cannot get the answers for this. I’m tring to write an API for my won software to talk to Meshtastic for Automation and a potential Native Windowsclient.
I’m coding on a platform ProtoBufs arent really available. not an issue I’m happy to implement them.
However there are some other problems. Changing coding platform is not an option and please dont reply with just use xyz and use the libraries. Please dont think me rude for saying this but I want to contribute/push Meshtastic further which will pretty quickly involve RISC-V and STM32 support and external hardware for the radios that do exist.
Once I have a serial connection I send out the magic bytes, lengths and then 0x18 0xA7 0xF8 0xCE 0xE3 0x02 the device then switches to packet mode and sends two uknown packets followed by a nodelist. This differs from expected behaviour in the docs but thats not an issue.
My problem is twofold at this point.
WHAT am I sending? What are these bytes? The docs say I should ask for a nodelist to switch to packet mode and thats what seems to happen but I dont know what I’m sending. i’d like to.
What are these packets coming back? I cannot match the tags to the types defined in the documentation and the overall packet structure isnt clearly defined anywhere I can see. All I see is I should expect the magic numbers, a packet length and then a Protobuff. Reading up on Protobuff my first byte after the length LSB should be the first tag in varint form but this makes no sense.
What I need is to grab a packet like : (these are dec values from the packet after LSB length with ASCII conversion after)
09:51:27 : 26 12 8 192 207 142 211 13 64 95 88 248 235 1 : …ÀÏÓ.@_Xøë.
09:51:27 : 106 28 10 13 50 46 51 46 52 46 101 97 54 49 56 48 56 16 22 24 1 32 1 40 1 64 171 6 72 43 : j…2.3.4.ea61808… .(.@«.H+
And then know what byte here is the first tag to start taking the stream apart. I’m used to working at a WAY lower level and I have a similar proprietory protocol used for vechile automation my company created. Once I can start pulling the tags out I’m golden as I can use the defs provided.
My (possibly wrong) gut feeling is that there is another un-mentioned encapsulation here. For example we dump a CRC on the end of our packets and a final check byte (We have to meet e mark requirements so belt and braces)
The documentation is pretty good but theres a fair few places where it just points you to a dead end or things just aren’t clear. As I normally work with devices that have a few Kb of RAM I dont have space to lift and shift whole libraries and protocol suites into my code, I also cannot use anything I have not audited personally so the “just use xxyyzz” isont one I have the luxry of using. I just need a little bit more low level detail on these packets in the docs so I can then roll my own.
