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.