Lat-long stamping


#1

We have a high value low power device , we want to use bluz on. The real value we could justify one in every device, is if the mobile gateway would stamp each packet that routes through it with location information.

I have done some iOS programming, and was responsible for the location object that I put into a reuse object we used for all our mobile apps. It was quite elegant to work with.

I see a source project for the Android app is available… (perhaps same for iOS)
It looks like the source for one of the Android apps is capable of being modified based on it’s open MIT license. I’m not up to speed on latest versions, but looks like a modest addition.

Any chance of the mobile clients incorporating a GPS data lat/long inside each packet that gets transmitted to the particle cloud ?

If not, perhaps writing a mobile app to do so, would not be a big reach as long as it was constantly connecting to the UUID from the bluz ?

Any ideas or comments are appreciated.


#2

The mobile app could not directly add data to packets coming from bluz and going to the cloud. In the architecture we use, the data is encrypted from the bluz board all the way to the cloud. The gateway cannot interpret the message, so it cannot add information to it. This is the most secure way of doing things, the gateway could not sniff information, but it also means the mobile app could not directly add information.

However, there is a way to do this. With the latest 1.1.47 firmware, the gateway (mobile app in this case) can directly send data to bluz and bluz can send data back to the gateway. So what you would do is have your bluz code keep track of the latest lat/long and have the mobile phone send it data whenever you needed to. Or, you could configure bluz to poll the mobile phone for it, that would work too.

So, your app would just get the location data, then send down the lat/long to bluz through this mechanism. Bluz would then had the data and could send it to the cloud however it wished.

The feature is a bit undocumented at the moment, but it is there and it does work. We have an example in the firmware repository, you can see it here: https://github.com/bluzDK/bluzDK-firmware/blob/develop/user/applications/custom_data_service/custom_data_service.cpp

This example is very simple, it just receives data from the mobile app and then responds to the mobile app. In the callback function, it just hands down a char array that you could easily have hold the lat/long.

To see how to alter our app to do this, you can see an example here: Direct Bluetooth connection from App(No Particle Cloud)

This is someone else’s app that is written in Objective C, but it shows how to send data. Our app is open source here: https://github.com/bluzDK/iOS-app. What you would want to do is use the send command, very similar to how we poll for the Device ID, you would just use a different code in the header. So this line https://github.com/bluzDK/iOS-app/blob/master/bluz-iOS-app/Libraries/BLEDeviceInfo.swift#L72 shows where we send down a header of 0x02. You would instead need to send a header of 0x04 along with your data.

I hope that makes sense. We will be adding more to this in the future, but this is completely possible today as well. If you have any questions, let me know and I would be happy to help walk you through it.


#3

Thanks for your prompt reply Eric. I’m a bit rusty on my current iOS SDK, but will either help me, or another hire we can get to invest the time to dig in further. The product is very exciting and the OTA, and API’s are making it a pleasure to develop in.


#4

Glad to hear you like bluz!

You can certainly do this in Android as well, our Android app is also open source: https://github.com/bluzDK/android-app


#5

Hi @eric,
Is it possible to change the header(which is 0x04 currently) in firmware?


#6

The header is used internally to our gateways and bluz to know where the packets should go. Why do you need to change it?