Best posts made by LeoDesigner

Hi everyone !

I needed a wired solution for my several nodes.
Here is the serial rs485/rs232 wired network transport for mysensors.
https://github.com/leodesigner/mysensors-serial-transport
It is based on the Majenko ICSC serial library.
Can you please test it? It is a beta version - but it is working for me.
(However, I am still waiting for my rs485 boards to arrive)
You can find more technical information at
http://sourceforge.net/p/arduino-icsc/wiki/RS-485/

To use it, you have to:

1. Put SerialTransport.cpp and SerialTransport.h to folder/directory/path SerialTransport in your library.
2. Add #include <SerialTransport.h> to your .ino sketch
3. Replace transport class with:
   MyTransportSerial transport(Serial,0,-1); // serial port, node, dePin (-1 disabled)

Please let me know about bugs and how it is working for you.

Hi everyone,
I have made some improvements to the Dallas Temperature Sensors example.

• made for non blocking main loop (useful for repeater and busy nodes)
  block time max 15ms for sensor read procedure
• it will remember a sensor index in EEPROM (2 bytes per sensor)
  in case if you need to replace or add a new sensor to the 1Wire bus - all other sensors will keep own sensor index

You are welcome to use it:
https://github.com/leodesigner/mysensors-arduino/tree/master/DallasTemperatureSensor_Recall

Check this solution too:
https://forum.mysensors.org/topic/2184/enhanced-dallas-temperature-example-with-permanent-sensor-index

Finally I am received my RS485 modules.
Here is the working example of gateway with two nodes:

RS485 Arduino transport for Mysensors.org – 00:14
— Axel Vivaldi

@AWI
The pseudocode looks correct, with one minor addition.
We may have corrupted incoming bytes received (or in our case just dropped) by the USART. So some kind of incoming byte waiting timeout should be implemented.

Please take a look here, to the bus arbitration process (J1708 NETWORK ACCESS part)

0_1478452964585_AN01230A.pdf

I hope we are not reinventing the wheel

One more interesting project to check:
https://github.com/MichaelJonker/HardwareSerialRS485/wiki/software-capabilities

@kimot
Just a quick look
http://www.aliexpress.com/item/MCP2551-High-Speed-CAN-Communicate-Protocol-Controller-Bus-Interface-Module/32472004400.html?spm=2114.031010208.3.27.bEv7Im&ws_ab_test=searchweb201556_1,searchweb201644_3_79_78_77_82_80_62_81,searchweb201560_1,searchweb1451318400_6148
They are five times more expensive.
But it might be another option for wired network too.
@andrej it is still a line not a star topology.

One more idea regarding cheap collision detection on the bus.
We can almost eliminate collisions on the bus (should be almost no lost packets at all).
Before packet transmission we need to check the bus state during one first byte time using digitalRead(rxPin). In this case collision may occur very rarely, because time between bus checking and actual first byte sending is very short.
Also the code modification will be very small in current library.

@redvoodoochild
You welcome, I hope it will be useful for you too.

@pjr said:

So we need collision AVOIDANCE and DETECTION for (almost?)perfect solution?

AVOIDANCE:

• line checking ( digitalRead(rxPin) ) what @LeoDesigner suggested

DETECTION:

• "listening what I just said"?
• checksum at receiving end?
• perhaps similar "hw ACK reply" as the radio is using?

With most important nodes I could additionally use controllers ACK functionality.

I hope we will finally will come to the right most perfect solution.
Let me say first: I am not saying that we should use only raw RS485. CAN bus is very good idea too. It's good to have alternatives. We can get some ideas from CAN protocol also. I like challenges, and right now it's like a getting something good out from dirt cheap staff.

So, how about this procedure:
Before packet will be sent:

• Collision AVOIDANCE: listen rxPin for time of one byte + few bits symbol interval
  • if bus is free: wait random time ( few bit's interval, 5-7) and check the bus again
  • if bus is free: start transmission of the first byte (start of the packet marker).

Collision DETECTION could be reliable done only via CHECKSUM ACK (small confirmation packet once we are received the input packet).

I think it's should be really rare case when two nodes will start transmission at the same time in case if we will make this random wait interval. Actually IMHO, Ethernet protocol using something like this (randomness before start).