[Sara Damiano]

The Arduino print function defaults to two decimal places for a float.  Normally, if you were using Serial.print(float) you could control the decimal places with Serial.print(float, decimalPlaces).  But because of the way the MS_DBG macro is written, that won’t work.  You’ll have to create a String from the number and then MS_DBG that:  MS_DBG(String(float, decimalPlaces));

[Sara Damiano]

I was reading up on the BLE support on the XBee3.  I think the only way to send data over Bluetooth is with Digi API frames.  You can use the on-board micropython, but from what I can tell, that uses the API frames under the hood.  So apart from having to figure out how to use the Mayfly to switch the XBee3 into API mode and properly chunk/format/send the SD card data into those frames, you’d have to figure out some way to take the frames you receive and turn them back into the data you want.  I *strongly* suspect that it wouldn’t be even close to worth the trouble to figure all those bits out and would just get a simpler Bluetooth device and leave the XBee3’s Bluetooth off.  My experience with the API frames on the XBee is that they’re a huge PITA and really hard to get right (as in, I couldn’t do it).

[Sara Damiano]

That’s great!  I’m sorry, I was imagining you had the entire set-up, Mayfly and all, running on batteries and sealed under water

[Sara Damiano]

You should be using the same modbus address that you use when connected to the computer.

Looking at the datasheet again, I told you the wrong connections.  I’m sorry.  Only Y/Z are available in half-duplex mode, not A/B.  So you need to move A->Y and B->Z.  Turn off the Y/Z termination dip switch (I think).  I also told you the wrong pins for DE/REnot.  They should be A5/A6 *not* A4/A5.

If fixing the wrong connections I told you to use doesn’t fix things, try disconnecting A5 and A6 and manually setting them at the start of your program.  Set DEREPin = -1; Then in your setup function, add this:


pinMode(A5, OUTPUT);
digitalWrite(A5, LOW);
pinMode(A6, OUTPUT);
digitalWrite(A6, HIGH);


Since it is a fully duplex chip, both the receiver and driver can be enabled at the same time, unlike half-duplex chips like the MAX485.

 

[Sara Damiano]

You’re not “overwriting” the serial connection.  The USB connection on the SAMD21 is a bit touchy and will fail if anything in the program fails.  In you’re program in lines 117 and 119 you’re calling Serial.println(...) and asking it to print the results of a function that returns void.  That’s most likely causing the crash.  It probably would be OK on an AVR board, but the SAMD21 is less forgiving.

Why don’t you start with the current version of the GetValues example from the YosemitechModbus library:  https://github.com/EnviroDIY/YosemitechModbus/blob/master/examples/GetValues/GetValues.ino.  It’s very different from what you had.  From there:

• delete line 16 (#include <AltSoftSerial.h>) and
• replace line 44 with HardwareSerial& modbusSerial = Serial1;
• in lines 33, use your real pin number controlling the Y4000 power, or -1 if you have it straight to a battery (and make sure the sonde really is powered!)
• in line 34, set the adapterPwrPin to -1; the shield you have is always powered
• in line 35, set the DEREPin to A4 or A5 (and make sure they’re tied together)

See if that compiles and runs.  Make sure your serial monitor is set to 115200.

After your getting some output, if you’re not getting values or the values are garbled or unreasonable, try adding the line sensor.setDebugStream(&Serial) right below the sensor.begin(..) in line 67.  Then post that output.

 

[Sara Damiano]

Did the extra power smoothing work for you?  I’ve noticed the issues with the WiFi XBee’s, but I wasn’t having them drop that frequently and we don’t have any “production” loggers deployed with WiFi, so I never bothered to try and fix anything.

[Sara Damiano]

I’m sorry, I’ve never tried anything with Bluetooth, so I’m only guessing here.

If the Bluetooth chip is that simple, and you have it connected to TXD and RXD on your Mayfly, you should print to the bluetooth using just Serial.print and not do anything with SoftwareSerial.  Serial is the TXD and RXD on the Mayfly.  You could also connect it to TX1 and RX1 and use Serial1instead of sharing with the FTDI/PC output.

The range of Bluetooth is very short under water (a few inches) so your users wouldn’t be able to do a float-by download.  They would most likely still need to pull the logger out of the water, and then initiate the Bluetooth connection.  Once it’s out of the water, though, you hopefully could get the data without actually opening the sealed box.

[Sara Damiano]

Oh, bother, and I missed that the chip on the RS485 shield does not have automatic flow control and the DE and REnot aren’t even on the same pin.   The library has support for a single DE/REnot pin, but for two separate pins.  You’ll need to physically join those pins for the library to work.  Run a jumper wire between A4 and A5 and then use either one of those for the DEREPin for the library.  In the past I’ve had almost no success in getting manual direction control to work properly.

[Sara Damiano]

Ok, I’m looking at the Arduino website now.

So it looks like the MKR is a SAMD21 based board, not an AVR based board like the UNO.  So, then, yes, just including AltSoftSerial will cause the code to fail to compile because AltSoftSerial is AVR only.

Based on the schematics, the MKR RS485 shield connects the Tx and Rx of the RS485 to Serial1 of the MKR1000 (and I assume whatever clone of that you have).  So that means you should delete everything related to SoftwareSerial, AltSoftSerial, or ESP8266.  In it’s place, you just need to add one line HardwareSerial& modbusSerial = Serial1; Then you should be able to use modbusSerial just like in the examples.

Apart from the code, you do need to make sure you’re supplying the Y4000 with enough power.  I’ve never actually touched a Y4000, but if I remember correctly it needs 12V and reasonable amperage.  That ISOVcc pin on the shield is *not* supplying power to the sensors.  The ISOVcc pin is part of the fail-safe for the chip that keeps the RS485 pins logic-high if something gets disconnected.  It should be connected to the Vcc of whatever you’re powering the sonde with (in addition to the Sonde power wire connection).   The same is true of the ISOGnd – it gets connected to the ground of the sonde power supply *and* the sonde’s ground wire, not only one or the other. Connecting the ISOVcc on the shield is optional (though I think the fail-safe won’t work without it).  The ISOGnd should be connected.

I think you also want to set your dip switches to “half duplex” and terminate the Y-Z since the Yosemitech is half-duplex A/B only.

[Sara Damiano]

@madbird – I’m sorry, I’m not at all familiar with the MKR or any of its shields.  For anything to work, you need to know what kind of serial port you need and how the pins are connected.  Merely creating and not using an AltSoftSerial instance shouldn’t be a problem at all.  But, of course, nothing’s going to work if you don’t tell the code the real port the device is connected to.

 

[Author]

Posts