Welcome to EnviroDIY, a community for do-it-yourself environmental science and monitoring. EnviroDIY is part of Home › Forums › Mayfly Data Logger › Bringing in serial data through UART on 20-Pin connector
- This topic has 5 replies, 3 voices, and was last updated 2020-06-17 at 6:45 PM by
Kurt Rosenberger.
-
AuthorPosts
-
-
2020-04-30 at 5:09 PM #14112Hello
I’m just getting started with the Mayfly, and am trying to bring in met data from an Airmar PB-100, using a GPS sketch I found for the Arduino (it is formatted as NMEA-0183, as they were
HelloI’m just getting started with the Mayfly, and am trying to bring in met data from an Airmar PB-100, using a GPS sketch I found for the Arduino (it is formatted as NMEA-0183, as they were built for boats). But my first hurdle is to even get the data in. I have an RS-422-TTL converter to bring the data in on the UART (I know this thing works because I’m successfully using one with a RasPi), but am unclear how I specify the pin for RX0 on the 20-pin header – is it A5, D0, RX0? All the examples I see for specifying pins seem to be referring to one of the digital pins. Any advice would be greatly appreciated.
Thanks
Kurt
-
2020-04-30 at 6:38 PM #14113Are you sure you need to use UART 0 for your incoming data from your deice? The RX0/TX0 pins on the 20-pin header are directly wired to the main UART 0 of the Mayfly, which are the same pins that arAre you sure you need to use UART 0 for your incoming data from your deice? The RX0/TX0 pins on the 20-pin header are directly wired to the main UART 0 of the Mayfly, which are the same pins that are used when programming the Mayfly board via your computer (using either the USB port of the FTDI header). So if you have a device connected to RX0/TX0 of your Mayfly, and that device is actively sending data to the Mayfly, then you won’t be able to program your Mayfly while that device is connected, or view data on the IDE via the SerialMonitor. Unless you’re using UART 1 for something else (like a bee module in the Mayfly bee socket) then I would suggest you connect your serial device to UART 1 using the RX1/TX1 pins instead.
If you want to use one of the other digital pins (the other 20-pin header on the adjacent side of the Mayfly) then you could use one of the pins like D4, D5, D6, D7, D10, D11, or a few others, but only if you aren’t using those pins by something else on your board or in your sketch, and only if you implement SoftwareSerial via libraries. However, SoftwareSerial has issues and limitations, so it’s better to use a hardware UART instead if it’s free.
-
2020-04-30 at 7:04 PM #14114I’m just seconding what Shannon said about using the hardware UART – always use hardware UART unless you definitely cannot. In your case where you’ll be parsing long NMEA sentencesI’m just seconding what Shannon said about using the hardware UART – always use hardware UART unless you definitely cannot. In your case where you’ll be parsing long NMEA sentences, I’d recommend actually re-wiring your Bee/modem to give your GPS the better connection if you’re trying to use both. In your code, you just use “Serial1” to communicate over the RX1/TX1 exactly like you would use “Serial” when writing to the computer. AltSoftSerial is the next best alternative – on the Mayfly with AltSS Rx will be on pin 6 and Tx on pin 5 (and only those pins). Like Shannon said, you can use any pin that allows pin-change interrupts for SoftwareSerial (which is nearly any digital pin on the Mayfly) but you are more likely to have misread data using it.
-
2020-06-11 at 2:25 PM #14191Hi Shannon and Sara
Thank you for your replies – yes, I was not able to communicate with the Mayfly while I had data coming in, so I will switch to RX1/TX1. However, I’m still not clear o
Hi Shannon and SaraThank you for your replies – yes, I was not able to communicate with the Mayfly while I had data coming in, so I will switch to RX1/TX1. However, I’m still not clear on how to designate that in the initial setup in the sketch. It was fine with A6 and A7, but when I try to use A8/A9 or RX1/TX1 in the ‘static const’ declaration, it won’t compile. Attached is the example sketch I’m using. Thanks again for your help
Attachments:
-
2020-06-11 at 5:41 PM #14193OK, I got it to work. The original sketch called for use of SoftwareSerial, and I replaced this with Serial1, and I realized that if I use Serial1, I don’t have to designate the pin numbers. GotOK, I got it to work. The original sketch called for use of SoftwareSerial, and I replaced this with Serial1, and I realized that if I use Serial1, I don’t have to designate the pin numbers. Got the Airmar plugged into the correct pins (A7 and A8), and voila, data coming in! Now my next task is to figure out how to log the 1Hz data to a buffer of some kind and do some averaging before writing to file. Any recommendations welcome! Thanks again!
Kurt
-
2020-06-17 at 6:45 PM #14252Folks
OK, I have data coming in, and can print to serial to see the output on serial monitor. Now I’m having a lot of difficulty declaring the new variables in my sketch in order to log the dat
FolksOK, I have data coming in, and can print to serial to see the output on serial monitor. Now I’m having a lot of difficulty declaring the new variables in my sketch in order to log the data using the LoggerBase, and I think it might be how the author of the GPS C++ code that I’m using set up the structures and classes in the header file. I honestly know very little about C, I’ve mostly use Matlab, so some of this seems familiar, but not familiar enough. I’d rather not mess with the GPS code, as it is currently working for me, but if I have to, some expert advice would help. Attached is my current sketch, and the GPS code I’m using. Any advice would be greatly appreciated.
Attachments:
-
-
AuthorPosts
- You must be logged in to reply to this topic.
