iOS Experiments

1

Hi,
I have spent a few years experimenting with GoTenna’s SDK and built a couple of projects:

Looking for a new challenge I have started to look at how I can link Meshtastic to the iOS ecosystem and the results of my first tests are:

iphone-and-android
iphone-and-android844×704 593 KB

This is very early proof of concept and I have used some “glue” hardware, in the form of a Raspberry PI.

The Raspberry PI code comprises two python scripts, one implementing a BLE UART service and the second acting as a wrapper between the UART service and the T-Beam device, using the Meshtastic libraries.

The iOS client is built around the Nordic Semiconductor protocols for their IOS-nRF-Toolbox and some basic UI stuff.

8 Likes
2

The “Glue” hardware is:

t-beam
t-beam700×619 85.6 KB

Using a Micro-USB to Micro-USB OTG cable, I did start with a PI-3 but the PI-Zero is capable of supplying sufficient power for the T-Beam.

3 Likes
3

Apologies for the poor image (the display I used had Ground & VCC swapped round - hence the jumper cables).

But I have moved forward today, dropping the Raspberry PI and python code out of the stack and can connect directly to the T-Beam from a iOS device, using CoreBluetooth:

pairing
pairing861×472 85.9 KB

It is worth noting that although you cannot pair in Bluetooth settings only through the App code, the Meshtastic device is then listed settings.

My test app is successfully talking to the T-Beam, although at the moment I have not looked at building up the correct message format as the debug console is throwing “Error: can’t decode protobuf end-of-stream, pb_msgdesc”.

2 Likes
4

@MeshTK, are you planning to submit this to the AppStore?

5

Super cool! An iOS app is consistently at the top of the list of what people want.

2 Likes
6

@meshjay, @geeksville it would be great if I can get this is the position where it can be submitted to the App Store, but at the moment I have only been working with Meshtastic devices for the last few days, so its impossible to put any timescales on what can and cannot be achieved.

It is also worth bearing in mind that this is very much a part time project fitted around family and work commitments and the approach to this will be different to Mesh Developers Toolkit (https://apps.apple.com/us/app/mesh-developers-toolkit/id1342708841) which I started to extend Mesh functionality from pure messaging to linking up with other devices (e.g. a lightening detector), before a python API was available.

Meshtastic already offers a great Python API - so it makes no reason for me to replicate this, but the Idea of building a client for iOS does appeal, as does the open nature of the platform.

I also need to understand better how the stack works (although I think I have the basics) and adopt an approach which will allow me to work alongside the core Meshtastic project.

Although I could pick up the c++ code and refactor it to work with Objective-C, I need to come up with a method that allows me to keep in sync with the main code base - if that makes sense.

Which is very different to the work on Mesh Toolkit where I was working with a SDK which offered a level of abstraction from the low level message formatting.

I would hate for Meshtastic to be getting flak over something stupid I had done code wise.

Although on a positive note, the next steps that I will be looking at to address is the use of protocol buffers and binary encoding…

1 Like
7

The internal meshtastic api is fully exposed on Bluetooth, tcp and http with protobufs.

Take a look at the protobufs in GitHub:

Write up:

2 Likes
8

re: limited time for this
yep - I totally understand - definitely only do what you have time for and is fun to work on.

re: wouldn’t want meshtastic to catch flak over something dumb in the code
don’t worry about that - we already do plenty of dumb things in the code - though hopefully less as time progresses :wink:

if you ever want to put your cool project in the meshtastic github you are also welcome to do that (just send me a note and I’ll do the github goo)

2 Likes
9

Of course :slight_smile:

In the mean time, it would be cool to build ourselves when you feel comfortable sharing the code

2 Likes
10

Thank you for your replies.

@mc-hamster thank you for the links - that has clarified my understanding of the underlying API and startup sequence - I have successfully generated and built the Meshtastic protobufs into a iOS App but not hooked it up with the Bluetooth code yet.

@geeksville, @meshjay, it makes sense to put code into the gitlab, although at the moment my code is very rough, being pulled out of another project.

I also might split my work into two - the front end code and a shared library to handle sending and receiving messages to the device (possibly based on a subset of the Python interface) - any thoughts on this approach?

2 Likes
11

Hi,
Been fighting with an issue where data I send from the iPhone to the T-Beam always throwing the same error:

*Trigger powerFSM 9*
*Error: can't decode protobuf invalid wire_type, pb_msgdesc 0x0x3f407c29*
*Error: ignoring malformed toradio*

I think that the data I am sending is ok and I have also written out the binary data from the Python client and tried sending this through the iOS client with the same result - Is there any way I can get the console to dump the hex data for this?

If I send dummy data to the device I get a different error:

Error: can't decode protobuf end-of-stream, pb_msgdesc 0x0x3f407c29

Thank you in advance.

2 Likes
12

Can you compile your own firmware binaries?

Right below the debug message on line 33 of mesh-pb-constraints.ccp, add this:

    for (int i = 0; i < srcbufsize; i++)
        Serial.print(srcbuf[i], HEX);

That should work, I have not tested it.

2 Likes
13

Any good news on the ios app?

5 Likes
14

hi @mc-hamster,
Finally got around to installing PlatformIO and moved forward using the code snippet and have now got packets being decoded - thank you.

To get packets to be decoded I had to send the data without the first 4 bytes (0x94,0xC3 and the packet length) - I found this by using the Android app against my firmware build which also not having the header in the stream - does this make sense?

Now need to work on building proper toradio packets :slightly_smiling_face:

4 Likes
15

Oh yeah, I had to strip the same 4 bytes when exposing the protobufs over the rest api. Thanks for sharing!

16

Oh yes. Those four bytes are only needed in the streaming apis (serial or TCP). They are not used for Bluetooth because datagram protocols have implicit framing.

The api doc.md should say something about this.

1 Like
17

It did, it just didn’t make sense until running into it.

1 Like
18

@geeksville, how about supporting also UDP over IP? This would allow all Meshtastic devices, within the same IP net, create a mesh on UDP and transfer packets as they do within the LoRa mesh: LoRa mesh -> node -> UDP over IP mesh (WLAN client) -> node -> LoRa mesh

Users should essentially be able to control/configure UDP streaming within python also, for unleashing their mesh creativity. :wink:

1 Like
19

There’s a plan to support this sort of feature using MQTT. It’s on the roadmap :slight_smile:

2 Likes
20

Just an update on progress - although I have successfully sent messages between two T-Beams, progress has ground to a halt down to hardware problems…

Neither of the two T-Beams, I purchased in October, have managed to record any satellites and the one T-beam will occasionally lock up.

When looking at the possibility of using a better antenna it was found that the ufl connectors appear to be not properly fixed to the boards - on the one board the connector separated from the board and either the insulator or solder balls dropped out.

Can anyone confirm if this is the insulator or the solder:

IMG_5145
IMG_5145596×565 25.8 KB

If it’s the insulator, the only sign of solder appears to be a tiny amount on the one side - if it’s the solder I assume that the antenna was shorting out.

In either case my soldering skills are anywhere near good enough to re-fix the connectors :frowning_face:

3 Likes