Welcome to EnviroDIY, a community for do-it-yourself environmental science and monitoring. EnviroDIY is part of WikiWatershed, a web toolkit designed to help citizens, conservation practitioners, municipal decision-makers, researchers, educators, and students advance knowledge and stewardship of fresh water. New to EnviroDIY? Start here

RS485 without auto direction control

Home Forums Mayfly Data Logger RS485 without auto direction control

Viewing 16 reply threads
  • Author
    Posts
    • #13456
      Erik G
      Participant

      I trying to set up a Mayfly logger with two Y504 oxygen sensors but are running into some problems.

      I could not get my hands on any of the RS485 modules you are using in the examples and had to try one I had on the shelf.

      This is is the module I’ve been using with 3.3V Arduinos before:
      Mikroe rs485 3.3v click

      The module work with the examples supplied in the YosemitechModbus\examples\GetValues
      (using “const int DEREPin = 4;”)

      I know you recommend a modules with automatic direction control but I just want to check if anyone made any progress with this.

      If I set max485EnablePin to anything else than -1 the logger program restarts after/during sensor test:

      “Logger portion of setup finished.
      Attempting to connect to the internet and synchronize RTC with NIST

      Setting up sensors…

      Now running OxygenScout on Logger 00001

      Using ModularSensors Library version 0.23.15”

      I’m using the version 0.4 of the Mayfly logger and EnviroDIY_ModularSensors 0.23.15.

    • #13460
      Sara Damiano
      Moderator

      I have never gotten the communication to work correctly using manual flow control, but it should not be causing your board to restart. I’ll look into it.

      When using manual flow control, you have to set the direction pin high or low to change directions. The library does this, but I think there is a timing issue or something because my attempts at using it with a max485 and level shifters compeletely failed.

    • #13461
      Sara Damiano
      Moderator

      Also, I’m really surprised you couldn’t find an adapter with automatic flow control. Where were you looking? There are a bunch on Amazon. This is one brand I’ve bought: https://www.amazon.com/SMAKN%C2%AE-Adapter-Serial-Converter-Module/dp/B010723BCE

    • #13462
      Sara Damiano
      Moderator

      Ok, I broke out the 3.3V RS485 chip I have (an LTC1480) from the “someday I’ll test this” box. I’d bought the chip ages ago to try out in place of the (5V) MAX485 that I couldn’t ever get to work. But since the automatic flow control always worked nicely, I threw the LT1480 onto a shelf unopened.

      Anyway, it worked for me. I made some very small tweaks to the SensorModbusMaster library to see if I could get the timing better, which helped a little, but it worked even without. I didn’t have any issues with the board restarting or anything.

      Hm.. In my test I used AltSoftSerial (pins 5&6) as my serial and tried the RE_/DE on both pins 4 and A2. What exactly are your connections and what code exactly are you running?

    • #13463
      Sara Damiano
      Moderator

      I was feeling cocky after the LTC1480 worked and pulled out the Max485 and level shifters. Zero success with communication, but I didn’t have any problems with the program crashing.

    • #13465
      Erik G
      Participant

      Wow, I just realized I didn’t really post any real question and still you are helping=)I’m really thankful and impressed by all your effort.

      I have ordered a module with automatic flow control from Amazon but I didn’t want to wait for it to arrive so I started with what I had.
      The module I have has been working nicely before but this time I can’t get it to work. In the past the timing turning the Enable pin low has been tricky for me. For simple programs I’ve used delays but I tried something like Nick Gammon’s solution under “Flushing the output” RS485 communications. But not in this case.

      I using the “logging_to_ThingSpeak”-example with one Yosemitech Y504, AltSoftSerial (pins 5&6) and RE/DE on pin 4.
      On my module the RE/DE are coupled together so you only need one pin. The restart happens even if I disconnect everything from the Mayfly logger. And the only way to stop it from happen is to set the “max485EnablePin” to -1. I will try some more examples to see if I can get it right with my coding.

    • #13471
      Erik G
      Participant

      I’m totally lost. Tried the “data_saving”-example as is and the logger restarts even if I keep the enable pin at -1. Doesn’t make a difference if I detach everything from the Mayfly and I tried both different usb-cables and FTDI-cable.

      The “thingspeak” example works if I don’t add any Yosemitech libraries/sensors in the code. I wonder if I’m doing anything wrong with PlatformIO? I have to add https://github.com/SRGDamia1/NeoSWSerial.git and https://github.com/EnviroDIY/SoftwareSerial_ExternalInts.git
      to the “platformio.ini” of the “data_saving”-example even if the .ini-file on github don’t use it.

      Tried the same code with a Sodaq Mbili and it behaves exactly the same.

      Anyone who can help me where I should start with the debug?

    • #13475
      Sara Damiano
      Moderator

      Oops. I’d meant to cut the code using NeoSWSerial and SoftwareSerial from that particular example but apparently cut it only from the example platformio.ini file.

      Can you post your platformio.ini file? Are you using Atom or VSCode? It shouldn’t make a difference for the code; I’m just asking so I can help you better. What versions of all libraries do you have installed? Did you install any manually or let PlatformIO do the install? Are you sure you haven’t installed any twice? In your project’s folder, navigate to the .pio/libdeps/mayfly subfolder and look at all the folders within it. Do you see any library names in there twice (with a different suffix tagged onto the end of the folder name). If you see any repeats, the easiest solution is to delete everything and let PlatformIO reinstall just one version of each. Then update all your libraries and your platforms if you haven’t already. To do this, open a new terminal in PlatformIO with either the button or the menu. On Atom you can use the + icon on the bottom; on VSCode there should be a button on the very bottom left that looks like this: [> ]. In the terminal first update the platforms with the command “pio update”. Then update your project specific libraries with the command “pio lib update.” PlatformIO itself hasn’t been updated in a while, but you can verify that you’re running the lastest version with the command “pio upgrade.” After updating everything, make sure you clean out any older pre-compiled files by hitting the trashcan icon.

      When you say the board restarts, does it restart instantly or does it hang for 15 minutes and then restart? Please add these defines to your platformio.ini file and then post the output when the board is running. It might be very long; you can post it or attach it as a text file.

    • #13476
      Erik G
      Participant

      To answer your questions:

      -I’m using platformio on VSCode. (I’m really not comfortable using it but these kind of problems is good for actually learning hands on. There is a lot of strange things in there that I don’t understand and I wish I could find a really good tutorial how to work with it.)
      -Attached my “platformio.ini”
      -I’ve tried both manual install and to let platformio do it.
      -Now updated/upgraded/cleaned
      – This is how the lib_dep folder looks like:
      v libdeps\mayfly
      >tmp_installing-kgja50_package
      >AltSoftSerial
      >NeoSWSerial
      >SoftwareSerial_ExtInts
      -I was pretty sure AltSoftSerial was the problem since I got some errors when including it when using the mayfly board both in Arduino
      IDE and platformio but that seems to work now.
      -If I now focus on the “data_saving”-example which I know I didn’t corrupt with my own programming I might be misinterpreting the output
      based on my past problems with my own code (modified version of the Thingspeak example). When using your platformio.ini without the debugflags I get the output as attached in file “output1.txt”. Every 15 sec I get a new line of “Now running data_saving.ino on Logger XXXXX”
      When using the debug flags I get whats in output2.txt
      Then the Y504 seems to update. Maybe I was waiting for a output similar to the thingspeak-example? The testbutton didn’t work which made me assume something was wrong.

      The debug flags are very helpful. I totally missed to try them. The buffer setting in my terminal is probably to low to catch enough but i learned i can save the log to a text file with “pio device monitor > Filename.txt” in the terminal. Also very helpful.

      Oh I forgot to replace the gprsbee which I removed the

    • #13479
      Erik G
      Participant

      My reply is very hard to read especially when all my spacing got removed. Sorry for that:)

      Attaching a .ini didn’t work so here it is:

    • #13480
      Erik G
      Participant

      It feels like a memory leak but I can’t see why. I tried to modify the thingspeak example but then everything got messed up and the pins scramled. I’ll try with another computer and see if I can find the bugs in my code. Probably something very simple.

    • #13483
      Erik G
      Participant
    • #13485
      Erik G
      Participant

      Finally some progress when I got some help.

      In the modified ThingsSpeak sketch the constructor was the problem.
      YosemitechY504 y504_1(y504ModbusAddress1, modbusSerial, modbusSensorPower, max485EnablePin, y504NumberReadings); -> did not work
      YosemitechY504 y504_2(y504ModbusAddress2, modbusSerial, rs485AdapterPower, modbusSensorPower, max485EnablePin, y504NumberReadings);->Works. I don’t know how I lost one of the power pins but that explains why it worked better from the beginning.

      Back to the original problem…
      The logger crashes if I set the EnablePin to >0 and don’t set the -D MS_YOSEMITECHPARENT_DEBUG flag
      In setup the program enters and don’t return from varArray.setupSensors();

      In YosemitechParent.ccp (line 67-69) the debugStream is null if not in debug.

      In SensorModbusMaster (line 683-690) it ends up with the null pointer

    • #13487
      Sara Damiano
      Moderator

      I’m sorry I haven’t responded. My family is finally finished with a fun round of stomach bugs.

      Were you by chance talking with @neilh or did you just happen to get to the same place at almost the same time coincidentally? Neil wrote up a fix for this in the SensorModbusMaster library, which I just accepted. If you update that library, you should be getting the fix. It might take 24 hours or so for the PlatformIO registry to catch the update on the library; if you’re ready to get the fix NOW you can uninstall and reinstall SensorModbusMaster using the github link instead of the library name.

      With the fix in SensorModbusMaster, is it finally working for you?

      I”m sorry for not being more helpful sooner!

    • #13492
      neilh
      Participant

      Sara sorry about the stomach bug. Life is challenging when the rulers of the internal ecology get distracted with nasty bug invasions.

      thanks for the fix ~ I just noticed this conversation today.

      I think it was working with the AVR compiler as I had it all working for many months on a Mayfly (except that specific riparian monitoring Mayfly got stolen a couple of months ago). I’ve seen this problem before, that the AVR compiler has some defensive won’t execute a NULL pointer. Which is great. The NULL pointer came up in the ARM context, but I hadn’t regression tested it with the AVR.

      I haven’t looked at this AVR Mayfly RS485 DIR management as its a streams based environment. That is where the Auto Direction SOM works very nicely. I had no problems with it.

      Apologies if this is repeating something that everyone knows;
      Modbus is a packet of information. At the begin of the packet the RS485 driver half duplex goes to transmit, and then only when the complete Modbus msg is sent does the RS485 driver revert to receive.
      The reverting to receive is critical hard real time, as the modbus slave starts to respond shortly afterwards and I believe its specified at 3.5Character timings or about 3.5mS. Modbus also specifies for a packet that there should never be a gap between characters of more than 1.5Character timings or about 1.5mS.
      The RS485 SOM does this with a simple hardware timing. Resistor, Cap, Diode and buffer(schmitt trigger) I believe.
      For a streams based environment I believe its challenging.
      I did investigate this for an Ubuntu Linux build and compiled in a different set of drivers for an RS485 mode.
      For the streams based environment, turning the driver to transmit is easy and can be done before starting writing to the stream.
      However it requires an accurate time to detect, not just when the last byte in the packet is written to the hardware (and how does a stream know its the last byte especially if there is a multibyte FIFO for the Tx UART) but when that byte has completed transmission through the UART. So for a stream based environment, the driver needs to start a timer whenever the UART end of character interrupt is received, and if another character isn’t written into the UART in 1.5character timings (a 1.5mS) then it needs to switch the direction to receive.
      In the world of industrial designed systems for Modbus there are a number of potential solutions a) design a packet based interface for the Mega1280 UART- the UART supports end-of-byte transmission, but the driver guarenttees the Rx switch. b) use a MAX1348 driver which also has auto direction, but it requires +5V c) using a processor with UART that supports RS485 like the SAM51

      Well Solstice Salutations to everyone, I hope you have a good holiday – and that there is harmony with the anthropogenic masters, the gastric microbial ecology!.

    • #13527
      Erik G
      Participant

      I’m not expecting you to fix all my problems, but I’m very grateful for any help I can get. I prefer this kind of bug though…

      It was actually very instructive to go through the libraries and trying to learn how they work. It was driving me nuts when it was working with the deep debug flag but it finally made sense.

      I totally missed @neilh’s fix before doing the debug. I got some help and was doing some serial debug through the libraries before reaching the conclusion. I have now learned I can check out github for known issues before trying to find them myself=)

      I was trying to add a Null stream object (since someone pointed me in that direction) but didn’t finish in time so I deployed with the debug flag. Will try the fix later.

    • #13531
      neilh
      Participant

      Hi Erik, Sounds like we ended up working on the same issue at about the same time.
      Great to hear you have a basic path forwards. I am very much a fan of the open source ModularSensors and EnviroDIY which covers a lot of functionality.

      However, it is a matrix of south bound (away from internet) instrument sensor interfaces ~~which are fantastic~~ and north bound (towards internet) communication interfaces.
      I personally have just a few configurations that I’m trying to build for the future, very much with RS485/12V (and SDI12/5V as instruments support it).
      From the software engineering aspect of the open source, there is no regression defined. So I’m attempting a definition of that.
      SO interested how it works for you.

Viewing 16 reply threads
  • You must be logged in to reply to this topic.