I'm working with a ELM327 and I'd like to be able to set the header and data portions of CAN messages to be sent. I see that there is a code for setting the header for messages
SH xxyyzz
But I'm having trouble finding out how to set the data portion and control when the message gets sent.
Do these both occur when I send a ASCII request for a PID with extra characters for the data field?
And would that use the header that was set by the SH command?
Is there a better way to do this?
Datasheet: http://elmelectronics.com/DSheets/ELM327DS.pdf
If you're using the ELM327, and you're on a protocol such as J1850 vpw, or J1850 pwm (older than 2003 CAN vehicles).. Then you will use this to set the header.
The header will consist of xx yy zz
xx = priority of message (i.e. 68)
yy = Target address of module you want to talk to (i.e. 5A)
zz = Sender address, which can usually be F1
So your command would look like this ATSH 68 5A F1
This sets the header.. Now you want to send data. Any data you send from now on will use that header, and send the data to that module.
So if you wanted to get the RPM's, you can just send 01 0C
You will get something like 41 0C 23. The last data byte is the value of RPM's. You will have to figure out the formula to convert this into a human readable format though.. A lot of information can be found here..
https://en.wikipedia.org/wiki/OBD-II_PIDs
By the way, if you're communicating on a CAN network, you would just use the module ID as the header.. ATSH 7E0, then send your data. all vehicles 2008+ are CAN.. some 2003-2007 are also.
This might be an old question, but I just found an online link which describes in detail how to send arbitrary CAN messages using the ELM327. So anyone (like me) coming past that question can still find a valid answer.
Look here for details on send arbitrary CAN messages with the ELM327:
https://www.elmelectronics.com/wp-content/uploads/2017/11/AppNote07.pdf
Best
If you're using an ELM327 chipset, you need to call ATSH or AT SH, to set the header first. Then send the message separately (The data bytes).
https://www.sparkfun.com/datasheets/Widgets/ELM327_AT_Commands.pdf
Related
I have an IoT device, which communicates with a cloud server via UDP. The device receives a command to turn on/off every couple of seconds based on a cloud schedule.
I believe the chip inside the device is similar to an arduino pro mini. It has an external serial to wifi bridge which "opens" the UDP connection to the server.
Commands from server:
CMD22246A00M10C239S004!9S1$
CMD22246A00M10C239S280!WM0$
CMD22246A00M10C075S960!X2I$
CMD22246A00M10C239S520!ME5$
CMD22246A00M10C075S811!EPJ$
I will explain the data a bit in case that helps.
Time in these packets is 22:46
The first 2 stands for Wednesday (0 being Monday)
A00 basically means turn off (supply 0 amps) - This changes to A10 when it is allowed to turn on
M10 is the maximum configured amps the devices should be allowed to pass through
CXXX I have no idea about
SXXX I have no idea about
And the 3 alphanumerics between the ! and $ seem to be a checksum. The letters are always uppercase.
The device reports data back to the cloud similarly with a 3 alphanumeric checksum at the end
I have tried "injecting" command data into the device via a separate UDP server but they are all have no effect unless I replay valid ones from the server.
I have tried various online tools and checksum/crc calculators but cannot seem to find any matches.
Thanks in advance.
Update
I have just started to notice that similar packets have a very similar "checksum" at the end. Here is a link to all my data from every Wednesday at 23:46, sorted alphabetically which gives the best string matches when starting left. I have started to notice that data that is "+1" to its neighbour, might have the checksum be +1 in the first character of the checksum.
Full data set here: https://pastebin.com/n6LgrDfh
Same data but split with symbols removed: https://pastebin.com/Q8q4ANEE
I have split these examples and removed the symbols for easier reading:
CMD22346A10M10 C075 S274 FZD
CMD22346A10M10 C075 S275 EZD
CMD22346A10M10 C075 S276 DZD
CMD22346A10M10 C075 S277 CZD
CMD22346A10M10 C073 S515 P60
CMD22346A10M10 C073 S516 Q60
CMD22346A10M10 C073 S517 J60
Update 2
There are never any letter O in the check characters.
I am unable to understand the CANopen Protocol. I am aware of the working of CAN and how a CAN frame looks like. A CAN data or remote frame contains the Start of Frame , Message Identifier Field, DLC, RTR , Data(Payload), CRC , ACk fields, etc. I am aware that the CANopen standard utilizes the CAN bus to send the CAN messages. However , the way in which a CANopen's CAN frame looks is different where it contains a COB ID+Node ID in the Message identifier field and in the payload field , it contains object dictionary related information. I would like to ask the following questions therefore:
How are the object dictionaries defined. I am aware that it is a
table containing an ID , sub ID, Datatype information about the data
it contains , the manufacturer information for the respective data
entry , etc . Are they all hard coded as an m*n multidimensional
array in the software stack?
I am confused with the terms transmit PDO and Receive PDO. Is it similar to CAN data frame and CAN remote frame ?
What is PDO mapping and how can i identify which object ID in the object dictionary is mapped to which object ID in the PDO mapping
table. Both use the same terms Object ID ?
I am actually very new to CANopen and i have asked these questions based on my initial understanding. I was unable to find a detailed explanation in the CiA website.
Thank you in advance
Krishna
It is not so easy to understand it!!
CanOpen is a communication between Master (client) and Slave (server).
An device like a sensor is a Slave.
The slave has an OD (object directory). The manufacturer provides all informations about it. Ex. if i want to read the temperature, its location is at adress 0x2040 at sub index 00. Then the master (our system) needs to make this request. To do this, you need to configure the device by sending some request (with SDO) in order to change the TPDO1 mapping (0x1A00) and TPDO1 communication parameters (0x1800). And be able to receive by the device the temperature. The device will not work alone.
SDO (read/write) allows OD access entries. Ex. change the TPDO1 mappings.
PDO is the output/input to the device once operational.
There is NMT Master commands to put the device in operational mode or to send a SYNC or Heartbeat. Depends what the device needs?
Ex. 080h 00 : SYNC send by master
280h 06 E5 EF 02 00 00 00 : response of device by TPDO2
000h 02 01 1F : put the device with ID = 1F in operational mode
If you want a good example device POSITAL FRABA absolute rotary encoder with can open interface.
Hope this will help you a little bit!!!
I want to send files(text or binary) through winsock,I have a buffer with 32768 byte size, In the other side the buffer size is same,But when the packet size <32768 then i don't know how determine the end of packet in buffer,Also with binary file it seems mark the end of packet with a unique character is not possible,Any solution there?
thx
With fixed-size "packets," we would usually that every packet except the last will be completely full of valid data. Only the last one will be "partial," and if the recipient knows how many bytes to expect (because, using Davita's suggestion, the sender told it the file size in advance), then that's no problem. The recipient can simply ignore the remainder of the last packet.
But your further description makes it sound like there may be multiple partially full packets associated with a single file transmission. There is a similarly easy solution to that: Prefix each packet with the number of valid bytes.
You later mention TCustomWinSocket.ReceiveText, and you wonder how it knows how much text to read, and then you quote the answer, which is that it calls ReceiveBuf(Pointer(nul)^, -1)) to set the length of the result buffer before filling it. Perhaps you just didn't understand what that code is doing. It's easier to understand if you look at that same code in another context, the ReceiveLength method. It makes that same call to ReceiveBuf, indicating that when you pass -1 to ReceiveBuf, it returns the number of bytes it received.
In order for that to work for your purposes, you cannot send fixed-size packets. If you always send 32KB packets, and just pad the end with zeroes, then ReceiveLength will always return 32768, and you'll have to combine Davita's and my solutions of sending file and packet lengths along with the payload. But if you ensure that every byte in your packet is always valid, then the recipient can know how much to save based on the size of the packet.
One way or another, you need to make sure the sender provides the recipient with the information it needs to do its job. If the sender sends garbage without giving the recipient a way to distinguish garbage from valid data, then you're stuck.
Well, you can always send file size before you start file transfer, so you'll know when to stop writing to file.
I tried using PARSE on a PORT! and it does not work:
>> parse open %test-data.r [to end]
** Script error: parse does not allow port! for its input argument
Of course, it works if you read the data in:
>> parse read open %test-data.r [to end]
== true
...but it seems it would be useful to be able to use PARSE on large files without first loading them into memory.
Is there a reason why PARSE couldn't work on a PORT! ... or is it merely not implemented yet?
the easy answer is no we can't...
The way parse works, it may need to roll-back to a prior part of the input string, which might in fact be the head of the complete input, when it meets the last character of the stream.
ports copy their data to a string buffer as they get their input from a port, so in fact, there is never any "prior" string for parse to roll-back to. its like quantum physics... just looking at it, its not there anymore.
But as you know in rebol... no isn't an answer. ;-)
This being said, there is a way to parse data from a port as its being grabbed, but its a bit more work.
what you do is use a buffer, and
APPEND buffer COPY/part connection amount
Depending on your data, amount could be 1 byte or 1kb, use what makes sense.
Once the new input is added to your buffer, parse it and add logic to know if you matched part of that buffer.
If something positively matched, you remove/part what matched from the buffer, and continue parsing until nothing parses.
you then repeat above until you reach the end of input.
I've used this in a real-time EDI tcp server which has an "always on" tcp port in order to break up a (potentially) continuous stream of input data, which actually piggy-backs messages end to end.
details
The best way to setup this system is to use /no-wait and loop until the port closes (you receive none instead of "").
Also make sure you have a way of checking for data integrity problems (like a skipped byte, or erroneous message) when you are parsing, otherwise, you will never reach the end.
In my system, when the buffer was beyond a specific size, I tried an alternate rule which skipped bytes until a pattern might be found further down the stream. If one was found, an error was logged, the partial message stored and a alert raised for sysadmin to sort out the message.
HTH !
I think that Maxim's answer is good enough. At this moment the parse on port is not implemented. I don't think it's impossible to implement it later, but we must solve other issues first.
Also as Maxim says, you can do it even now, but it very depends what exactly you want to do.
You can parse large files without need to read them completely to the memory, for sure. It's always good to know, what you expect to parse. For example all large files, like files for music and video, are divided into chunks, so you can just use copy|seek to get these chunks and parse them.
Or if you want to get just titles of multiple web pages, you can just read, let's say, first 1024 bytes and look for the title tag here, if it fails, read more bytes and try it again...
That's exactly what must be done to allow parse on port natively anyway.
And feel free to add a WISH in the CureCode database: http://curecode.org/rebol3/
I am about to write a message protocol going over a TCP stream. The receiver needs to know where the message boundaries are.
I can either send 1) fixed length messages, 2) size fields so the receiver knows how big the message is, or 3) a unique message terminator (I guess this can't be used anywhere else in the message).
I won't use #1 for efficiency reasons.
I like #2 but is it possible for the stream to get out of sync?
I don't like idea #3 because it means receiver can't know the size of the message ahead of time and also requires that the terminator doesn't appear elsewhere in the message.
With #2, if it's possible to get out of sync, can I add a terminator or am I guaranteed to never get out of sync as long as the sender program is correct in what it sends? Is it necessary to do #2 AND #3?
Please let me know.
Thanks,
jbu
You are using TCP, the packet delivery is reliable. So the connection either drops, timeouts or you will read the whole message.
So option #2 is ok.
I agree with sigjuice.
If you have a size field, it's not necessary to add and end-of-message delimiter --
however, it's a good idea.
Having both makes things much more robust and easier to debug.
Consider using the standard netstring format, which includes both a size field and also a end-of-string character.
Because it has a size field, it's OK for the end-of-string character to be used inside the message.
If you are developing both the transmit and receive code from scratch, it wouldn't hurt to use both length headers and delimiters. This would provide robustness and error detection. Consider the case where you just use #2. If you write a length field of N to the TCP stream, but end up sending a message which is of a size different from N, the receiving end wouldn't know any better and end up confused.
If you use both #2 and #3, while not foolproof, the receiver can have a greater degree of confidence that it received the message correctly if it encounters the delimiter after consuming N bytes from the TCP stream. You can also safely use the delimiter inside your message.
Take a look at HTTP Chunked Transfer Coding for a real world example of using both #2 and #3.
Depending on the level at which you're working, #2 may actually not have an issues with going out of sync (TCP has sequence numbering in the packets, and does reassemble the stream in correct order for you if it arrives out of order).
Thus, #2 is probably your best bet. In addition, knowing the message size early on in the transmission will make it easier to allocate memory on the receiving end.
Interesting there is no clear answer here. #2 is generally safe over TCP, and is done "in the real world" quite often. This is because TCP guarantees that all data arrives both uncorrupted* and in the order that it was sent.
*Unless corrupted in such a way that the TCP checksum still passes.
Answering to old message since there is stuff to correnct:
Unlike many answers here claim, TCP does not guarantee data to arrive uncorrupted. Not even practically.
TCP protocol has a 2-byte crc-checksum that obviously has a 1:65536 chance of collision if more than one bit flips. This is such a small chance it will never be encountered in tests, but if you are developing something that either transmits large amounts of data and/or is used by very many end users, that dice gets thrown trillions of times (not kidding, youtube throws it about 30 times a second per user.)
Option 2: size field is the only practical option for the reasons you yourself listed. Fixed length messages would be wasteful, and delimiter marks necessitate running the entire payload through some sort of encoding-decoding stage to replace at least three different symbols: start-symbol, end-symbol, and the replacement-symbol that signals replacement has occurred.
In addition to this one will most likely want to use some sort of error checking with a serious checksum. Probably implemented in tandem with the encryption protocol as a message validity check.
As to the possibility of getting out of sync:
This is possible per message, but has a remedy.
A useful scheme is to start each message with a header. This header can be quite short (<30 bytes) and contain the message payload length, eventual correct checksum of the payload, and a checksum for that first portion of the header itself. Messages will also have a maximum length. Such a short header can also be delimited with known symbols.
Now the receiving end will always be in one of two states:
Waiting for new message header to arrive
Receiving more data to an ongoing message, whose length and checksum are known.
This way the receiver will in any situation get out of sync for at most the maximum length of one message. (Assuming there was a corrupted header with corruption in message length field)
With this scheme all messages arrive as discrete payloads, the receiver cannot get stuck forever even with maliciously corrupted data in between, the length of arriving payloads is know in advance, and a successfully transmitted payload has been verified by an additional longer checksum, and that checksum itself has been verified. The overhead for all this can be a mere 26 byte header containing three 64-bit fields, and two delimiting symbols.
(The header does not require replacement-encoding since it is expected only in a state whout ongoing message, and the entire 26 bytes can be processed at once)
There is a fourth alternative: a self-describing protocol such as XML.