After decoding AIVM sentences using gpsdecode I have a buch of json estructures, each one with all the data of a message type, for example:
{"class":"AIS","device":"stdin","type":1,"repeat":0,"mmsi":224047690,"scaled":true,"status":15,"status_text":"Not defined","turn":"nan","speed":0.0,"accuracy":false,"lon":-8.7296,"lat":42.2401,"course":231.9,"heading":511,"second":36,"maneuver":0,"raim":true,"radio":114776}
{"class":"AIS","device":"stdin","type":4,"repeat":0,"mmsi":2240998,"scaled":true,"timestamp":"2018-05-19T16:34:35Z","accuracy":true,"lon":-8.7877,"lat":42.1717,"epfd":7,"epfd_text":"Surveyed","raim":false,"radio":165192}
My problem is that position messages (type 1,2,3) doesn't have the complete UTC just a reference in seconds between 0-60, which is the correct way to obtain the complete UTC for this messages?
The timestamp is NOT present in the AIS message.
The AIS system was initially created as a collision avoidance system, and was supposed to be used in real time, hence there was no need to transmit a timestamp.
If you receive a live AIS feed, you need to add the current timestamp immediately when you receive the message, and potentially use a queue to postpone the rest of the treatment.
The UTC_seconds field in the message is the second when the report was generated by the electronic position system, not a real timestamp. You can find all the fields transmitted in the messages 1, 2, 3 at https://www.navcen.uscg.gov/?pageName=AISMessagesA.
Related
I would like to receive the vehicle's CAN data to the socket CAN and send it to the server. (raw data)
Accordingly, CAN ID is very important in post-processing raw data sent to the server.
The CAN data ID received by Candump and wireshark is only 3 digits, so it is difficult to distinguish which data it is.
For example, although the CAN ID I need to receive is 0x1f532d10, only d10 is received and displayed from socketcan.
Is there any way to get the ID length as a whole?
If you're using SocketCAN to send frames you need to set the "Extended Frame Format" bit in the can_id field of the can_frame struct, e.g.:
frame.can_id |= CAN_EFF_FLAG;
I need to transfer data over a serial port. In order to ensure integrity of the data, I want a small envelope protocol around each protobuf message. I thought about the following:
message type (1 byte)
message size (2 bytes)
protobuf message (N bytes)
(checksum; optional)
The message type will mostly be a mapping between messages defined in proto files. However, if a message gets corrupted or some bytes are lost, the message size will not be correct and all subsequent bytes cannot be interpreted anymore. One way to solve this would be the introduction of limiters between messages, but for that I need to choose something that is not used by protobuf. Is there a byte sequence that is never used by any protobuf message?
I also thought about a different way. If the master finds out that packages are corrupted, it should reset the communication to a clean start. For that I want the master to send a RESTART command to the slave. The slave should answer with an ACK and then start sending complete messages again. All bytes received between RESTART and ACK are to be discarded by the master. I want to encode ACK and RESTART as special messages. But with that approach I face the same problem: I need to find byte sequences for ACK and RESTART that are not used by any protobuf messages.
Maybe I am also taking the wrong approach - feel free to suggest other approaches to deal with lost bytes.
Is there a byte sequence that is never used by any protobuf message?
No; it is a binary serializer and can contain arbitrary binary payloads (especially in the bytes type). You cannot use sentinel values. Length prefix is fine (your "message size" header), and a checksum may be a pragmatic option. Alternatively, you could impose an artificial sentinel to follow each message (maybe a guid chosen per-connection as part of the initial handshake), and use that to double-check that everything looks correct.
One way to help recover packet synchronization after a rare problem is to use synchronization words in the beginning of the message, and use the checksum to check for valid messages.
This means that you put a constant value, e.g. 0x12345678, before your message type field. Then if a message fails checksum check, you can recover by finding the next 0x12345678 in your data.
Even though that value could sometimes occur in the middle of the message, it doesn't matter much. The checksum check will very probably catch that there isn't a real message at that position, and you can search forwards until you find the next marker.
I'm writing a small app to test out how torrent p2p works and I created a sample torrent and am seeding it from my Deluge client. From my app I'm trying to connect to Deluge and download the file.
The torrent in question is a single-file torrent (file is called A - without any extension), and its data is the ASCII string Test.
Referring to this I was able to submit the initial handshake and also get a valid response back.
Immediately afterwards Deluge is sending even more data. From the 5th byte it would seem like it is a bitfield message, but I'm not sure what to make of it. I read that torrent clients may send a mixture of Bitfield and Have messages to show which parts of the torrent they possess. (My client isn't sending any bitfield, since it is assuming not to have any part of the file in question).
If my understanding is correct, it's stating that the message size is 2: one for identifier + payload. If that's the case why is it sending so much more data, and what's that supposed to be?
Same thing happens after my app sends an interested command. Deluge responds with a 1-byte message of unchoke (but then again appends more data).
And finally when it actually submits the piece, I'm not sure what to make of the data. The first underlined byte is 84 which corresponds to the letter T, as expected, but I cannot make much more sense of the rest of the data.
Note that the link in question does not really specify how the clients should supply messages in order once the initial handshake is completed. I just assumed to send interested and request based on what seemed to make sense to me, but I might be completely off.
I don't think Deluge is sending the additional bytes you're seeing.
If you look at them, you'll notice that all of the extra bytes are bytes that already existed in the handshake message, which should have been the longest message you received so far.
I think you're reading new messages into the same buffer, without zeroing it out or anything, so you're seeing bytes from earlier messages again, following the bytes of the latest message you read.
Consider checking if the network API you're using has a way to check the number of bytes actually received, and only look at that slice of the buffer, not the entire thing.
I'm having a problem about the Read Interval of my RFID Reader. The Read Interval and SameID interval are all set in x10ms which is declared in Byte. In configuration the max ms i can set is 255 ms and that is equal to 2,550 seconds. Can someone help me? This is the screenshot of the configuration.
Please the piture:
The SameID Interval in the form is in s but the max number is only 255
It is only the specification of the product you are using, and does not specify the behavior of the application program you make.
Applications can incorporate their own Same ID checks.
For example, when tag data is read from an RFID reader, it memorizes time and tag data pair in the application.
Every time the tag data is read, it compares it with the read data stored in the application, if there is the same tag data, compare it with the reading time, and if it is within the time specified yourself, read it later you can discard the data.
P.S.
You can also comment on the manufacturer and wait for it to be realized, or request and fund it to make a special product for you.
I've never worked with bluetooth before. I have to sends data via BLE and I've found the limit of 20 bytes per chunk.
The sender is an Arduino and the receiver could be both an Android or a Node.js app on a pc.
I have to send 9 values, stored in float values, so 4 bytes * 9 = 36 bytes. I need 2 chunks for all my data via BLE. The receiving part needs both chunks to process them. If some data are lost, I don't care.
I'm not expert in network protocols and I think I have to give each message an incremental timestamp so that the receiver can glue the two chunks with the same timestamp or discard the last one if the new timestamp is higher. But I'm not sure how to do a checksum, if I really need it or not, if I really have to care about it, or if - for a simple beta version of my system - I can ignore all those problems..
Does anyone can give me some advice? Like examples of similar situations handled with BLE communication?
You can get around the size limitation using the "Read Blob Request" of ATT. It allows you to read an attribute and also give an offset. So, you can use it to read the attribute with an offset of 0, if there's more than ATT_MTU bytes than you can request again with the offset at ATT_MTU*1, if there's still more ATT_MTU*2, etc... (You can read it in 3.4.4.5 of the Bluetooth v4.1 specifications; it's in the 4.0 spec too but I don't have that in front of me right now)
If the value changes between request, I'm not sure how you could go about detecting such a change. You could have the attribute send notifications when there's a change to interrupt the process in case the value changes in the middle of reading it.