CAN bus transport implementation for MYS
-
Hello,
I'm really interested in the solution you are working on (can bus with mysensors). I would like as much as possible to avoid a wireless network but I still would like to use the "mysensors" libraries and protocol. As this project as a lot of users it's a warranty of longevity.
@kimot : your trials seems great, did you have the change of getting further?
@gasuter
I think I am able sending data from node to gateway (GW) and through it to controller.
There is limited data space in CAN message, so I must avoid sending long strings and send all as possible like integers, longs, floats etc. It is not problem when sending from node to GW, because in the message header is field, which describes type of payload and according GW code, I assume, it can translate it to strings for controller correctly.
But problem is, when GW receives data from controller. Payload is always string and I must convert it to int, long, float and sometimes short string for sending it through CAN bus to the node. But from serial protocol GW can not recognize, what type of this payload is. I think I need to built some translation table for each serial protocol TYPE to variable type.
But maybe each controller sends different type of data for the same sensor value (0, 1 x "on", "off" ).
Or better something "smart" like "when there is a dot and not letter in string, it is float", "if there are only numbers, it is int or long" .... -
Sorry to hijack a bit, but j1708 looks like it can do bit level collision detection with a max485, it means controlling the DE line. More work than CANBus?
-
Sorry to hijack a bit, but j1708 looks like it can do bit level collision detection with a max485, it means controlling the DE line. More work than CANBus?
@wallyllama
I look at j1708 spec. and I think, that this protocol was born long before CAN.
It uses MAX485 bus drivers that way, that CAN bus drivers can works at higher speeds and better now.
And I must say, I can see better multimaster implementation for RS485 bus than j1708 ( clever addressing, bus arbitration, CRC instead of simple SUM etc. ) And there is AVR libraries so you do not start from scratch. For J1708 I can not find any. -
A friend of mine who works a lot with can bus told me that j1939 supports multi pack when bigger payloads are needed
@gohan
Thanks for your message.
All CAN controllers can send max 8 bytes of data, so longer messages must be divided to multiple packets. J1939 works this way too. That is what I do not want. With heavy traffic especially GW must again assemble packets to complete message, but packet of one message will not come one by one. Packets will be coming mixed from different nodes and GW must assemble them in memory to complete message from each node. So you for example has 30 messages in different state of completion. Some of them has received 1 packet and waiting for 2nd , some has 2nd and waiting for 3rd. ....
I am concerned that it does not work for ATmega328, and must be used processor with more RAM. -
@kimot Thank you very much for your reply. It's sounds great and more I read about bus for IOT more I think Can is the best solution. But still the problem with the data length bother me. The more hack and tricks we have to add to a system the more problem we can have.
I made a little research on internet about Can and found that there is a new version called CAN FD that is actually compatible with CAN 2 but it can be used at a higher speed between to CAN FD nodes (but that is not really interesting us for our use). The real plus is that you can send data up to 64 bytes. And I think that could be the solution of the problem, no?
-
@kimot Thank you very much for your reply. It's sounds great and more I read about bus for IOT more I think Can is the best solution. But still the problem with the data length bother me. The more hack and tricks we have to add to a system the more problem we can have.
I made a little research on internet about Can and found that there is a new version called CAN FD that is actually compatible with CAN 2 but it can be used at a higher speed between to CAN FD nodes (but that is not really interesting us for our use). The real plus is that you can send data up to 64 bytes. And I think that could be the solution of the problem, no?
@gasuter
CAN FD looks good, until you start to looking for IO chips.
MCP2561FD is only CAN bus transceiver ( like MAX485 ) with higher speed ability, then traditional CAN bus drivers.
It has no logic "on board".
You need something like MCP2517.
But try find datasheet, prices etc. for this chip.
I think, it will be very expensive way for us, like standard CAN several years ago was. -
Better performance usually means more expensive 😁. Maybe for the moment we just need to find a good way to make rs485 perform a little better
@gohan this is exactly why i brought up j1708, it is a hardware spec(can be any software on top), that uses max485 chips, you drive the de line instead of tx and it allows you to "see" collisions on the line. It would need a layer that does retransmits, but i dont see why the mysensors rs485 code clouldnt ride on top of that. There is an id that is utransmitted first that all nodes have to watch for which is duplicated efforst as the mysensors layer has that.
I see it like this pseudo code:
All nodes listen for an id,
if none, then start transmitting,
watching for dominant bits in between bits that hint someone else is transmitting, if collision back off for random time.
if no collision transmit full message as normal mysensors message
Other nodes must listen until message ends then they can start a transmit after random interval.The secret is really in tying tx (it looks like) low and control de, re is enables always so you can see other bits. Once a node has the bus, everyone shuts up until it is done. You only decides "who has the floor" and how to know when they relinquish it.
J1708 is 9600 baud, which may be ok, but ill bet it would work at higher speeds.
-
I am not sure if customizing too much that protocol is going to be a successful way. I'm concerned that if you can't get a team of developers working on it and maintain it in the future, people aren't going to use it because the risk of don't having any kind of support will discourage them
-
@gohan
Thanks for your message.
All CAN controllers can send max 8 bytes of data, so longer messages must be divided to multiple packets. J1939 works this way too. That is what I do not want. With heavy traffic especially GW must again assemble packets to complete message, but packet of one message will not come one by one. Packets will be coming mixed from different nodes and GW must assemble them in memory to complete message from each node. So you for example has 30 messages in different state of completion. Some of them has received 1 packet and waiting for 2nd , some has 2nd and waiting for 3rd. ....
I am concerned that it does not work for ATmega328, and must be used processor with more RAM.@kimot
Much agree with you, I don't like CAN bus, let's return to RS485 bus, I already create a stand alone RS485 controller chip (CDCTL-Bx) which support arbitration (as same as CAN) and user data in packet is up to 253 bytes, the baud rate is also higher than CAN or CAN FD, and it's much more easy to use than the CAN:
https://github.com/dukelec/cdbus_doc (Open Source Project) -
Hi all,
I would really be very interested in having CAN bus managed by MySensors.
My new house is being built and I already planed to have a RS485 bus running along the house (RJ45 cable with one pair dedicated to RS485 bus and one pair for gnd/+5V). Having done some tests, I realize that I'm facing a lot of collisions and I don't want to explain to my wife that the light does not switch on when she clicks the switch because of a collision ;)
So, I'm was looking at solutions based on CAN bus and was even ready to give up with MySensors (although I love mySensors) when I ended up on this thread.
@kimot : have you progressed on your implementation ?
If so, I'm OK for being your beta-tester, I only need to exchange integers between the nodes and the gateway, no strings so the limitation of the packet size is not an issue for me : 8 bits are sufficient to me. -
@gasuter
CAN FD looks good, until you start to looking for IO chips.
MCP2561FD is only CAN bus transceiver ( like MAX485 ) with higher speed ability, then traditional CAN bus drivers.
It has no logic "on board".
You need something like MCP2517.
But try find datasheet, prices etc. for this chip.
I think, it will be very expensive way for us, like standard CAN several years ago was.@kimot said in CAN bus transport implementation for MYS:
@gasuter
CAN FD looks good, until you start to looking for IO chips.
MCP2561FD is only CAN bus transceiver ( like MAX485 ) with higher speed ability, then traditional CAN bus drivers.
It has no logic "on board".
You need something like MCP2517.
But try find datasheet, prices etc. for this chip.
I think, it will be very expensive way for us, like standard CAN several years ago was.MCP2517 has been released a few months ago and is only around 2$.
http://ww1.microchip.com/downloads/en/DeviceDoc/20005688A.pdf
