Well Am writing a school project on class A AIS Transponder, in which I will show the nmea messages
sent out but yet to know all. So mine question goes
Apart from (AIVDM/AIVDO) AIS message type 1,2,3,4,5 which other message type is been sent out?
Also Apart from nmea sentences !AIVDO,!AIVDM,$GPGGA,$GPGLL,$GPGSA,$GPZDA which other sentences is been sent out?
A link to message logs of class A AIS Transponder will be welcome
Related
trying to figure out how to control the trainer. got this bluetooth HCI logs but unsure if there's a Method to "unlock" the trainer before sending the command.
This is the sequence which I'm seeing from the Manufacturer's App sent to the trainer.
I don't quite understand this particular output. It looks to me that this Char UUID has the Indication characteristic. Is the app actually sending anything to the trainer? I don't see a Value being written. (Is it correct to presume that all writes will have a Value Hex?)
This is sending 100w (6400 or 0064 in LSB) target power to the trainer.
This is sending 300w (2c01 or 012c in LSB) target power to the trainer.
Here are the 2 btsnoop logs from 2 different apps if anyone is willing/wants to look further.
https://www.dropbox.com/s/86wox4ywz3sjr2v/btsnoop_hci%28TrainerRoad%29.log?dl=0
https://www.dropbox.com/s/pgs6j4fg6opjrij/btsnoop_hci1%28Saris%29.log?dl=0
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.
I need to create a monitor, which will log information about packet missing using ZeroMQ ipc. Actually I don't really understand everything about it because of there are some LINX, TIPS protocols also. Can you please explain me that and answer the main question?
You could make the application self-monitoring, by including a message serial number in each message structure. The message sender keeps track of the serial number it last sent, and increments it every time it sends a message.
The recipient should then be receiving messages with ever-increasing message serial numbers embedded. If that ever jumps by 2 or more, a message has gone missing.
IPC is not lossy like a network can be - the bytes put in come out the other end. TCP is not lossy either, provided both ends are still running and the network itself hasn't failed. However, depending on the ZMQ pattern used and how it's set up whole messages can be undelivered (for example, if the recipient hasn't connected yet, etc). If that's what you mean by "packet missing", it would be revealed by including an incrementing message serial number.
I've been reading the rfc 7252 for a while and I am probably blind but I can't find how can I send a simple number (integer or float) when you answer a get request for a ressource (for example the sensor /light, where do you write it in the packet.
I think it's in the payload, so I tried to send this packet :
the option content-format text/plain, charset=utf-8, length 1
then I write 255(0xff) in the packet
then I write 0x34 in the packet (payload part).
But obviously it's not working, first I don't think I should use this option (probably another one but I can't find the good one to send either integer or float number), I'm not sure though if I'm in the right way and not sure anymore of what I am doing tbh, so that's why I'm asking.
Thanks for help,
Good bye
EDIT : Here are more info :
I'm using microcoap on arduino, using an ethernet cable between computer/arduino mega 2560.
wireshark info
After reviewing your Wireshark trace and seeing the response in Copper I think I see the problem. When you say that the Content-format is text/plain you are saying that you are sending ASCII data across. You say you send [0xFF 0x34] in your post, but in the trace you are actually sending is [0xFF 0x33]. Copper is showing you exactly what you are sending: 0xFF doesn't resolve as ASCII here and 0x33 is the ASCII for 3, which is shown in the Wireshark trace and in your Copper output window. If you want to send 2 raw bytes of data that shouldn't be interpreted as text you want to set your Content-format to be application/octet-stream.
guys need some insight here.
I know the definition of a protocol, being new to this c++ programming is quite a challenging
task.I am creating a Multi-threaded chat using SDL/C++, this is a learning experience for me
and now i have encounter a hump in which I need to overcome but understanding it is a little more difficult than I had thought.I need to make a chat protocol of some sort, I think...but am stump. Up until this point i have been sending messages in strings of characters.Now that am improving the application to the point where clients can register and login, I need a better way to communicating with my clients and server.
thank you.
Create objects that represent a message, then serialize the object, send it over the network, then deserialize at the other end.
For example, you could create a class called LoginMessage that contains two fields. One for a user name, and one for a password. To login, you would do something like:
LoginMessage *msg = new LoginMessage();
msg->username = "Fred";
msg->password = "you'll never guess";
char *serialized_msg = serialize(msg);
// send the bytes over the network
You would do something similar at the other end to convert the byte stream back into an object.
There are APIs for creating message objects and serializing them for you. Here are two popular ones. Both should suit your needs.
Protocol Buffers by Google
Thrift By Facebook
If you want the serialized messages to be readable, you can use YAML. Google has an API called yaml-cpp for serializing data to YAML format.
UPDATE:
Those APIs are for making your own protocol. They just handle the conversion of messages from object form to byte stream form. They do have feature for the actual transport of the messages over the network, but you don't need to use those features. How you design your protocol it up to you. But if you want to create messages by hand, you can do that too.
I'll give you some ideas for creating your own message format.
This is one way to do it.
Have the first 4 bytes of the message represent the length of the message as an unsigned integer. This is necessary to figure out where one message ends and where the next one starts. You will need to convert between host and network byte order when reading and writing to/from these four bytes.
Have the 5th byte represent the message type. For example, you could use a 1 to indicate a login request, a 2 to indicate a login response, and 3 to indicate a chat message. This byte is necessary for interpreting the meaning of the remaining bytes.
The remaining bytes would contain the message contents. For example, if it was a login message, you would encode the username and password into these bytes somehow. If it is a chat message, these bytes would contain the chat text.