Make some changes for slave side use

[jrzondagh]

Hi there,

I'm keen to make a few small changes to the lib to allow for slave side use.

E.g. slaves should not pull the line high for 12ms before sending command, but they should wait the min of 8.3ms before replying

Would you be able to make the changes, or shall I attempt it?

Regards, Justin

[Kevin-M-Smith]

Hi @jrzondagh - Great to hear from you!

I see your sensor-side SDI-12 repository and would be interested in contributing to it.

I think that this repository should only implement SDI-12 data logging functionality and keep all the sensor-side functionality in your repository.

Eventually we could change the name of this repository to help users distinguish between the two.

What do you think?

[jrzondagh]

Yeah sure, I figured that we can quite easily add the slave logic into your lib. You can see it in the fork I created.

I see the current lib being "Layer 2" and then the sketches I'm busy with as Layer 3/4/5 which interprets the protocol itself.

Essentially I just did the following to your lib:

• added global var and isSlave input into constructor
• instead of HOLDING in begin() we also go to LISTENING if a slave
• if isSlave, don't wake sensors in the sendCommand()

Still busy testing, will keep you posted and perhaps we can merge back and keep it backwards compatible.

[dwasielewski]

I wish I had seen this conversation months ago! I have been working on the same thing independently. My solution was slightly different. It is backward compatible as I did not modify anything, only added two functions:

• Do not modify the constructor.
• Add public void forceListen() function to address your second bullet (it should be called in the setup() of the sketch). Note: The more straightforward way is to make setState() public, but I was trying to avoid modifying existing functions.
• Add public void sendResponse() function to address your third bullet. Note: in addition to not calling wakeSensors() for a response, you must also call setState(TRANSMITTING) and, per SDI-12 spec, precede the response with an 8.33 ms LOW.

I've also created a generalized example sketch of how to implement an SDI-12 slave device. The modified lib and the example are publicly available in my fork off of this repository.

[jrzondagh]

Great news. I actually ended up doing a big refactor of the lib to no longer use interrupts. Going to fork it and share back soon

[Kevin-M-Smith]

Exciting stuff! Can't wait to see it. Doing it without interrupts may mean we can support ARM processors (e.g. Arduino Due).

On Aug 9, 2016, at 11:25 AM, Justin Zondagh notifications@github.com wrote:

Great news. I actually ended up doing a big refactor of the lib to no longer use interrupts. Going to fork it and share back soon

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[dwasielewski]

Wow! That sounds like a massive change; I'm curious to see how you implemented it. I suppose that would also resolve the SoftwareSerial incompatibility issue.

[jrzondagh]

Yeah. I'm using it on an Atmel SAMD21 / ARM Cortex M0 chip with great success. Will share in the next week or so.

[Kevin-M-Smith]

Hey @jrzondagh, how is this coming along? Any outstanding tasks we might be able to help with?

[ChrisInSingapore]

Coincidentally this has come at the perfect time for an arduino Zero project. I'm following and able to do a bunch of testing on M0 with a bunch of SDI-12 sensors if you need any of this done

[adnanoner]

@jrzondagh Hi Justin, how is this coming along? Is there anything I could help with?

[SRGDamia1]

I'm going to close this issue because the slave-side (d25b299) and M0 support (#33) have both been added.

The library is still interrupt based, and @jrzondagh if you have a solution for that I would LOVE to see it, but I'll leave that discussion to continue on #8 which is all about that.