We are building a real-time bus tracking system for a client. The buses send GPS data to the configured server in NMEA 0183 protocol.
We tested the configuration on one bus. Our NMEA parser on our server is able to decode the sentences and give us the latitude longitude of the bus location.
But we are unable to verify that the data is coming from that bus itself. So, how will we detect and parse data sent by multiple buses?
The buses send GPS data to the configured server in NMEA 0183 protocol.
The NMEA protocol is very wordy and contains duplicated fields in different sentences. It would be much more efficient to parse the NMEA sentences in the bus. Then you can send a "message" to the server that contains the parsed values and a bus ID: latitude, longitude, date/time, speed and bus ID. This message is 10 to 80 times smaller than the raw NMEA data. The records in the server can then be used to display bus locations.
If you are using an Arduino microcontroller to connect to a GPS module, you should take a look at my NMEA parsing library, NeoGPS. It is supported on all the Arduino platforms.
Related
I have a use case for connecting with a arbitrary bluetooth device (not a scanner). I have the following questions -
Is it possible to connect data wedge to a random bluetooth device to send and receive data? I was unable to find any example online in docs or elsewhere. The idea is that the bluetooth device will dump data to its outputstream, and i am hoping data wedge can pick it up and insert in my app field.
Can data wedge also send requests to the bluetooth device? ( Or can it only be a listener and receive data? ) If yes, how to we configure the request string and frequency.
In our use case the data is a long string (eg - "a,b,c,d"). My idea is to send this string to a text field and then segregate it in application itself.
Our use case is for TC 56 devices. As i understand it, the application app listens for the intent data wedge generates post scanning. Can it work seamless on laptops as well? The service in our use case is a web app.
I'm implementing a bacnet library to read and write some object instances.
But I don't understand, why with a PC and with an application like Yabe if I ask to a common controller to read more than 300 objects, the segmentation is supported, instead with a mobile phone and on the same request to the same controller the segmentation is not supported.
Both the PC and the smartphone are in the same network on Wifi.
So what is the problem/difference?
It is nothing to take with a PC or a mobile phone. Any IP compatible devices mobile phone, desktop, laptop, Arduino chips will work with BACnet.
Your problem is segmentation. You will have to handle the segmented messages coming from the Controller.
Every BACnet controller vendor specifies the MaxApduLength (i.e max length of data to be transferred within one UDP packet). The standard APDU length is 1476 bytes. So a BACnet controller cannot send the data more than the length of APDU specified within it.
Requesting 300 objects from a controller results definitely in a large APDU than the controller's limit. In this case Controller will send you segmented messages each with sequence number. You will have to handle this all segmented messages and combine them in one message then only you will get exact response. This is same with Yabe and other BACnet clients.
I have also written BACnet libraries for our mobile applications in Java and Swift 4.0 and both can read any number of objects from controller with segmentation support added. I have tested these with controllers having more than 400 objects.
Segmentation is used for APDUs (responses) that are too large to fit in one frame on the datalink. If both devices support segmentation, then great. If one of the device does not support segmentation, and the APDU does not fit, then "Segmentation not supported" error is issued. (and you have to then retry a smaller request).
I recently aquired a Segway Ninebot ES2 electric scooter. I can connect to the scooter via Bluetooth LE and grab information such as battery status, current mileage, temperature, and so on. This is all done through an application.
On my Android device, I've successfully extraceted the HCI log file, which I imported into Wireshark. I can see all the requests and commands send back and forth between my phone and the scooter. However, the requests and responses are all garbage and I have no idea how to interpret them.
Example of a sent command (info says Sent Write Command, Handle: 0x000e (Nordic UART Service: Nordic UART Tx))
Example of the received value I got right after (info says Rcvd Handle Value Notification, Handle: 0x000b (Nordic UART Service: Nordic UART Rx))
How am I supposed to interpret these responses? If the battery status was 59%, I would expect it to return something like 0x3b (0x3b hex is 59 decimal). But honestly, I have no idea how this works. Maybe they're returning a bunch of data in a data type only their app knows how to interpret? Like JSON for web.
Here's an example from the nRF Connect for Mobile application, where I hit the down arrow on all the characteristics: https://i.imgur.com/hREDomP.jpg (large image)
And probably more important: How do I replicate a request or command in nRF Connect? I've tried sending a byte array that looks like 0x {02410011000d.....} (from the Write Command) in the application, but I have no idea how to read the response.
If someone is still interested, I did the same research for this scooter.
That's standart BLE communacation, device offers BLE "services" and "characteristics". Service can contain one or more characteristics, by which you communicate with device. Each charateristic can allow different types of interaction with it: writing into it, reading from it, subscribing to notifications (so you dont have to to manually read, it kinda pushes data to your app), and more (read here, for example)
Take a look at your wireshark screenshot: you can see Service UUID, Handle UUID (the characteristic), and handle ID. You can communicate with device via uuid or id, depending on your programming language or library (more about uuids).
In this particular scooter there are two characteristics, one allows writing into it, another - allows subscribing to it. Together, they act like RX and TX wires in UART: you write data into one and read from another. So, to begin communication with scooter you must establish connection to it, subscribe for notifications from one ch, and write data to another.
As for protocol: look again at she screenshots, "UART Tx" is the actual payload that was sent to scooter and "UART Rx" was the response. Yes, it's binary data, that only app would understand. Luckily, protocol has been reverse engineered and is well documented. In your example app requests serial number, and it's returned in response - "N2GWX...". In order to request battery percentage you must build another payload according to protocol.
I'm not sure if it's still relevant, but at least for those, who will be interested in the topic.
You can try the following to understand how to interpret response from the device.
An option to consider is to fetch manufacturer's mobile app (apk) either by adb or from sites like apkmirror, etc.
Then apply some reverse-eng tool like JADX.
If you're lucky and the code is somewhat readable, then search for smth that has to do with response (like ResponseParser) and try to find algo that is used to interpret the response.
However, the very first attemp should always be to search on github/google if smb did it already for your device, unless it's very niche.
Hallo Android developers,
i am creating an app to meassure datas with the Body sensor such like an ecg does. I am able to messure the heart rate.
But I want to get the raw data in [mV] of the Body sensors.
There are just TYPE_HEART_RATE and TYPE_HEART_BEAT to use.
Has anyone an solution to get the raw values over time?
It would be pretty fine if we can start a discussion about this Topic.
I found Access Raw Sensor Data that might be of help:
The Sensors API lets you to read raw sensor data in your app in real
time. Use this API to:
List data sources available on the device and on companion devices.
Register listeners to receive raw sensor data.
Unregister listeners to stop receiving raw sensor data.
The Sensors API does not automatically store sensor readings in the
fitness store, and sensor registrations created with the Sensors API
are not persisted when the system restarts. You typically use the
Recording API to
record data in the background with persistent subscriptions, and you
use the Sensors API to display or process sensor readings in real
time. In many cases, you use both of these APIs in your app.
I am analyzing the traffic beacons generate using tshark and iptraf. I know they are mainly used to determine the proximity of a device and like any other network device the traffic generated by them must be having a header and payload information in it.
What is best way to find out the payload information though header info can be identified as to where packet is being sent etc , but how we can classify the payload and what information it contains in a beacon signal , is it the same like any other web traffic sent and receive on a network or is it different since they make use of Bluetooth ?
Any pointers regarding would be useful .
Bluetooth LE beacon transmissions are much simpler than the HTTP protocol. They are transmit only and have no real headers, although there are short segments within the transmissions called PDUs that have a similar purpose.
To see an example of a beacon transmission, see my answer here:
What is the iBeacon Bluetooth Profile