[Sara Damiano]

Great that you’re using PlatformIO; it really is a big improvement over the Arduino IDE!

Do you mind sharing your platformio.ini file? It should look very much like this:

INI

; PlatformIO Project Configuration File ; ; Build options: build flags, source filter ; Upload options: custom upload port, speed and extra flags ; Library options: dependencies, extra library storages ; Advanced options: extra scripting ; ; Please visit documentation for the other options and examples ; http://docs.platformio.org/page/projectconf.html [platformio] src_dir = logging_to_EnviroDIY [common] platform = atmelavr framework = arduino lib_ldf_mode = deep lib_ignore = RTCZero lib_deps = ModularSensors@>=0.6.7 https://github.com/PaulStoffregen/AltSoftSerial.git https://github.com/EnviroDIY/SoftwaterSerial_ExternalInts.git [env:mayfly] board = mayfly

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

; PlatformIO Project Configuration File ; ;   Build options: build flags, source filter ;   Upload options: custom upload port, speed and extra flags ;   Library options: dependencies, extra library storages ;   Advanced options: extra scripting ; ; Please visit documentation for the other options and examples ; http://docs.platformio.org/page/projectconf.html   [platformio] src_dir = logging_to_EnviroDIY   [common] platform = atmelavr framework = arduino lib_ldf_mode = deep lib_ignore = RTCZero lib_deps =     ModularSensors@>=0.6.7     https://github.com/PaulStoffregen/AltSoftSerial.git     https://github.com/EnviroDIY/SoftwaterSerial_ExternalInts.git   [env:mayfly] board = mayfly

The “lib_ignore = RTCZero” is needed for AVR boards (like the EnviroDIY Mayfly). That library is for SAMD boards (like a Sodaq Autonomo or Arduino Zero) that have a clock in the processor. If you don’t tell PlatformIO to ignore the library it will try to build it and you’ll end up with errors like you’re seeing. Also the “lib_ldf_mode = deep” might be needed because sometimes it misses dependencies otherwise.

[Sara Damiano]

Ok, I hate to admit this, but I’m baffled as to why that example is failing. It really should be working. You do need to change the server IP address (DL) on your XBee to 129.123.41.212 because the server’s IP address has changed. Other than that, everything looks great to me… but the server isn’t responding to the request.

So, in the meantime, don’t use that example to try to send data to the EnviroDIY portal. Instead, use the EnviroDIY logger library in the ModularSensors library. There are a lot of sensors that the library already supports and we’d love your contributions if you want to add more.

To use ModularSensors, you’ll need a whole bunch of other libraries installed. You can get them all here: https://github.com/EnviroDIY/Libraries.

The coding structure has changed enough that you cannot just paste the “code snippet” for your site into the example, but it sounds like you’ve already figured out how to get the GUID’s you need, so you shouldn’t have trouble placing them where they need to go.

Please let me know if that doesn’t work for you! If you want to try making the post requests by hand, I’d recommend the ‘Postman’ app for google chrome. Make sure you add in the request body; it looks like that’s why your other test to the server failed.

[Sara Damiano]

I haven’t tried running that particular example in a long time, but I don’t think the POST request format has changed since it was first developed. The server definitely *is* accepting data right now; my online loggers have up-to-date data. I’ll go back to that example and see what happens for me.

[Sara Damiano]

I’m sorry I’ve missed this thread until now.

I agree that when interfacing with a 12V powered device through the RS485 adapter, there shouldn’t be much risk of frying the Mayfly. I would still go with a separate power boost instead of stripping the resistors on the Mayfly, though.

I would *NOT* recommend any RS485-to-TTL adapters based on the MAX485/MAX3485 chip. Getting the timing right for the enables is *really* tricky and I haven’t been able to get it to work successfully at all. I have bought a couple of boards with automatic flow control (looking similar to the one Calvin pictured) and all of them have worked.

WRT Modbus communication, I have not tried to interface with In-situ probes yet, but in working with other sensors I found the ModbusMaster library to be really confusing. I ended up writing my own library to handle modbus interfacing with sensors. It’s specifically written with someone who knows very little about modbus in mind. That library is on GitHub if you’re interested: https://github.com/EnviroDIY/SensorModbusMaster

[Sara Damiano]

I’m sorry, I’ll have to look into why you’re getting some values that are too high.

[Sara Damiano]

I’m sorry for the library download trouble! How are you trying to download them? The easiest way is to get all the libraries for the Arduino IDE is pull them all together from the libraries repo: https://github.com/EnviroDIY/Libraries. If you scroll down, there are instructions for the Arduino IDE and PlatformIO. This will probably pull in some other libraries that you aren’t interested in, but they’re very small files so it shouldn’t be a problem.

[Sara Damiano]

If you don’t want to be limited as to which pin each library can control, you can set the pin change interrupt as “master” and use a different version of software serial that has been stripped of all interrupt register control: https://github.com/EnviroDIY/SoftwareSerial_ExternalInts.

You could also use AltSoftSerial instead of SoftwareSerial because it doesn’t need interrupts. It can only be used with pin D6 as the receiver and D5 as the transmitter. You cannot use pin D4 if using AltSoftSerial.

To use AltSoftSerial with a Mayfly or Mbili you must add these lines to the top of your sketch:

#define ALTSS_USE_TIMER1 #define INPUT_CAPTURE_PIN 6 // receive #define OUTPUT_COMPARE_A_PIN 5 // transmit #define OUTPUT_COMPARE_B_PIN 4 // unusable PWM

1 2 3 4

#define ALTSS_USE_TIMER1 #define INPUT_CAPTURE_PIN 6 // receive #define OUTPUT_COMPARE_A_PIN 5 // transmit #define OUTPUT_COMPARE_B_PIN 4 // unusable PWM

[Sara Damiano]

If you’ve downloaded the libraries from https://github.com/EnviroDIY/Libraries, then you should be able to fix it by replacing (in your sketch, not in the library) every instance of “SoftwareSerialMod” with “SoftwareSerial_PCINT12” and “Sodaq_PcInt_Mod” with “Sodaq_PcInt_PCINT0”.

Essentially, what happened is that these libraries all conflict with each other because each tries to monopolize all of the interrupt control registers within the processor chip. The processor in the Mayfly has 4 grouped interrupt registers (vectors 0-3 or A-D) which control interrupts on 8 pins each. Several years ago, Shannon made modified versions of the Software Serial and PcInt (and SDI12) libraries to force each to only work with a specific interrupt vector (instead of each trying to use all 4). At that point, she added the “mod” to each library name to note that it had been modified. As you noticed, sometime after she wrote the examples, I renamed those libraries from “mod” to “PCINT#” to specify which of the interrupt vectors each library had been modified to control.

Because the modified versions do only have control of specific interrupt vectors (instead of all of them) you have to be careful which pins you try to use with each library:
– Sodaq_PcInt_PCINT0 only works on vector A/0, so you can only assign interrupts to pins D24-D31 (aka A0-A7) using that library. If you’re only using this to assign a wake-up interrupt from the clock, which is attached at A7, that’s fine.
– SoftwareSerial_PCINT12 only works on vector B/1 & C/2, so you can only fake a serial input/output on pins D8-D23. The way the pins on the Mayfly are routed, the only pins exposed in a grove jack for SoftwareSerial_PCINT12 are D10&D11. The Mayfly does have two hardware serial ports (which are always superior to a software serial port imitation) but these are taken up by the communication with the FTDI chip (ie, the communication with the USB) and the communication with the “Bee” socket.
– SDI12_PCINT3 only works on vector D/3, so you can only use it on pins D0-D7.

[Sara Damiano]

You should also be able to use pin-change interrupts for the tipping bucket, which would allow you to use any pin at all. Using pin change interrupts requires an extra library, though. I’m a fan of GreyGnome’s EnableInterrupt library, which I’ve modified to have all the right pin numbers for the Mayfly: https://github.com/EnviroDIY/EnableInterrupt

The external interrupts do have priority over pin-change interrupts, but I don’t imagine the bucket would tip so fast that you’d have any problems, especially when your ISR is just a count.

All pin change interrupt libraries also conflict with the interrupts defined by SoftwareSerial and the SDI-12 library, although there are fairly easy work-arounds for those if you need them.

[Sara Damiano]

The red cable from the MaxTemp goes to pin 1 on the MaxSonar. The shield (yellow) and black cables from the MaxTemp both go to pin 7 on the MaxSonar. Pin 7 on the MaxSonar is also connected to ground (black) from the grove, so you’ll be shoving three wires into the MaxSonar screw terminal at Pin 7. Pin 6 on the MaxSonar goes to Vcc (red on the grove). Pin 5 on the MaxSonar goes to D2/white on the grove, if you want to use pin 5 on the Mayfly to receive data.

In your data sketch, you then need to set up an instance of SoftwareSerial with the Rx set as pin 5. Then you want to use the parseInt() function to capture the data from the MaxSonar. (But throw away the first 6 lines from the MaxSonar after power-up, because it sends out a header before sending out data.) There’s an example sketch here: https://github.com/EnviroDIY/EnviroDIY_Mayfly_Logger/blob/master/examples/mayfly_sonar/mayfly_sonar.ino

You can also use the ModularSensors library (https://github.com/EnviroDIY/ModularSensors) with the MaxSonar, if you’d prefer.

[Author]

Posts