Can Audrino Collect Data Ouput from 2 Devices and Show it LCD Display?

Hey everybody I have a project that I think I can make happen using Audrino but wanted to ask to get some guidance.

I build portable solar power systems for a living www.PortableSolarPower.Biz and I'm looking for a way to take the data output feeds from two different devices and then display the data from both devices on 1 LCD Display so all the data is in one place.

I am assuming that Audrino can take in the data from both devices and then output that data onto one of the LCD screens that are available online.

The 2 devices that I am using that output data are different and output data in different formats.

The 1st device I am using is a Solar Charge Controller that outputs data in MODBUS format: The Data Sheet for this Solar Charge Controller is located here http://us.pv-contractor.com/us_store/index.php/us_us/aitdownloadablefiles/download/aitfile/aitfile_id/4578/

The 2nd device I am using that outputs data is the Victron Battery Monitor and it outputs data in the format outlined in this document http://www.victronenergy.com/upload/documents/BMV%20Text%20Protocol.pdf

So I need a Audrino board that is super efficient that can accept the output formats from both devices and have softward on the Audrino board that can process this data and send it out to a external LCD display in a organized format.

How difficult could this be for somebody who knows how to program Audrino?

I want to integrate this LCD display into portable solar power systems we build at www.PortableSolarPower.Biz

All feedback is Greatly appreciated!

Hey SolarDude, I quickly looked over the links you have attached and it looks like you just need 2 UART ports.
The Arduino only has one real hardware UART port, but there is a software serial library which will allow you to create a software UART port on any 2 pins of an Arduino.
That being said, any programmer can easily get this setup to work with an Arduino. Just have to understand all the commands in the manual.

Jay

jayjay1986:
Hey SolarDude, I quickly looked over the links you have attached and it looks like you just need 2 UART ports.
The Arduino only has one real hardware UART port, but there is a software serial library which will allow you to create a software UART port on any 2 pins of an Arduino.
That being said, any programmer can easily get this setup to work with an Arduino. Just have to understand all the commands in the manual.

Jay

Thank you very much for your feedback and I'm glad this is mainly a programming issue and the hardware is readily available.

I'll have to dig into learning about UART ports but I saw this board on Kickstarter and though it would be really nice if something this small and cheap would work for the task http://www.kickstarter.com/projects/digistump/digispark-the-tiny-arduino-enabled-usb-dev-board?ref=search

I'll have to dig into learning about UART ports but I saw this board on Kickstarter and though it would be really nice if something this small and cheap would work for the task http://www.kickstarter.com/projects/digistump/digispark-the-tiny-arduino-enabled-usb-dev-board?ref=search

That board on kickstarter does not have enough pins and possibly not enough memory for your project. You need at least an Arduino Uno. If you make your own board, I would consider using a 1284P that CrossRoads has based some projects around.

I have seen the digispark before. It is based around a Attiny85 from Atmel. It does not have any UART ports so you would be using purely software serial ports.
I am not sure if the current Arduino library will work with it but if it does, it should be pretty strait forward. I would recommend a Pro Mini (Store | Jaycon Systems) or Arduino Mini (http://arduino.cc/en/Main/ArduinoBoardMini) for the job since it is already supported and you can get one for just about the same price. It will be a lot easier to do on these boards.

Jay

jayjay1986:
I have seen the digispark before. It is based around a Attiny85 from Atmel. It does not have any UART ports so you would be using purely software serial ports.
I am not sure if the current Arduino library will work with it but if it does, it should be pretty strait forward. I would recommend a Pro Mini (Store | Jaycon Systems) or Arduino Mini (http://arduino.cc/en/Main/ArduinoBoardMini) for the job since it is already supported and you can get one for just about the same price. It will be a lot easier to do on these boards.

Jay

Thanks again.

So the Digispark could work with its 6 ports (2 pins for Data Input #1, 2 pins for Data Input #2, and 2 Pins for Serial Data I/O for LCD Screen)? The 2 input ports will need to be running software to turn them into the Serial Ports that are needed.

The thing I like about the Digispark is that it can accept up to 35v DC input for power and does not require a 3 or 5v power source. The systems use 12v batteries so with the Digispark I would not need any 12v to 3 or 5v down conversion to run the other 2 mini boards you linked to.

I'm wanting a nice screen like this to display the data all one time. MONOCHRON KS0108 Graphic LCD [white on black] : ID 253 : $30.00 : Adafruit Industries, Unique & fun DIY electronics and kits

Sounds good. You should be able to make it all work. I don't see any problems.
I would double check how much space the USB boot loader uses on the digispark, so you know how much flash memory you have left to work with.

Jay

That display you want take a lot of pins to make it work. Look at the pins required in the lower part of this page. Arduino Playground - GLCDks0108

To do all of the things you are asking for, it is starting to look like you need something based on the 2560 mega.

There are cheaper boards out there but, here is one for example. Arduino Mega 2560 R3 (Atmega2560 - assembled) : ID 191 : $39.95 : Adafruit Industries, Unique & fun DIY electronics and kits

Hey cyclegadget, I think he plans on using a Serial (I2S) Backpack for the LCD, in which case he should be OK.

Jay

Note, the kickstarter phase of digispark has closed 3 days ago. They do plan on offering digisparks for sale after the initial kickstarter pledges are sent out. At the moment, they are talking about general availability in December, but I've had some kickstarter campaigns that were 9 months late in delivering their rewards. There is the tweensy 3.0 that ends in 2 days, that will have 3 separate UARTs and is based on an Arm processor. While it will use similar libraries to that on the Arduino, it isn't and Arduino, and there may be some initial teething pains. I should mention that I have put money down for digisparks and tweensy.

If you are dealing with higher voltages, perhaps you want to use a Ruggeduino, which is better protected against high currents: http://ruggedcircuits.com/html/ruggeduino.html

jayjay1986:
Hey cyclegadget, I think he plans on using a Serial (I2S) Backpack for the LCD, in which case he should be OK.

Jay

Yes I plan on using the 2 wire Serial (I2S) for the screen.

Here is the data for the Digispark:

The all-important technical specifications are as follows:

Support for the Arduino IDE 1.0+ (OSX/Win/Linux)
Power via USB or External Source - 5 V or 7-35 V (automatic selection)
On-board 500ma 5 V Regulator
Built-in USB (and serial debugging)
6 I/O Pins (2 are used for USB only if your program actively communicates over USB, otherwise you can use all 6 even if you are programming via USB)
8k Flash Memory (about 6k after bootloader)
I2C and SPI (vis USI)
PWM on 3 pins (more possible with Software PWM)
ADC on 4 pins
Power LED and Test/Status LED (on Pin0)

Is 6k memory Ok for what I'm trying to do? I have no idea?

MichaelMeissner:
Note, the kickstarter phase of digispark has closed 3 days ago. They do plan on offering digisparks for sale after the initial kickstarter pledges are sent out. At the moment, they are talking about general availability in December, but I've had some kickstarter campaigns that were 9 months late in delivering their rewards. There is the tweensy 3.0 that ends in 2 days, that will have 3 separate UARTs and is based on an Arm processor. While it will use similar libraries to that on the Arduino, it isn't and Arduino, and there may be some initial teething pains. I should mention that I have put money down for digisparks and tweensy.

If you are dealing with higher voltages, perhaps you want to use a Ruggeduino, which is better protected against high currents: http://ruggedcircuits.com/html/ruggeduino.html

Thanks for the suggestion! The extra protection is not needed for this project but you never know into the future.

It really depends on how much data we are talking about. If it is tens of bytes in a second, it is probably fairly easy to do it in an Arduino/digispark, and you likely won't need a hardware URT (which can help with the buffering, etc.). If you are dealing with lots of data, particularly if the Arduino has to do a lot of number crunching, then the Arduino might not be able to keep up, or have enough memory to process the data. In that case you probably want to go to a faster processor with more memory (such as an Arm based processor).

If you don't have to use a serial line, and can design the other two pieces to talk to the Arduino, you could have them be SPI or I2C devices. If they are existing devices, you have to adapt to the fixed format.

MichaelMeissner:
It really depends on how much data we are talking about. If it is tens of bytes in a second, it is probably fairly easy to do it in an Arduino/digispark, and you likely won't need a hardware URT (which can help with the buffering, etc.). If you are dealing with lots of data, particularly if the Arduino has to do a lot of number crunching, then the Arduino might not be able to keep up, or have enough memory to process the data. In that case you probably want to go to a faster processor with more memory (such as an Arm based processor).

If you don't have to use a serial line, and can design the other two pieces to talk to the Arduino, you could have them be SPI or I2C devices. If they are existing devices, you have to adapt to the fixed format.

I'm not really sure how much data is being sent out per second between the 2 devices but its probably a decent amount of data. I'm clueless about bits and bytes but somebody would have to look at the data outputs to see exactly how much data were talking about.

Here is some data about the MODBUS data output format and a list of data points that are avaliable to pull from.

The solar charge controller SunSaver MPPT - Morningstar Corporation has a regular RJ11 phone jack data port on it so I have no idea how I would interface that with the Adurino input.

General Information

The SunSaver MPPT supports the industry standard MODBUS® application protocol via its Meter RJ-11
interface. A Meterbus to Serial Converter (MSC) is required to adapt the Meter interface to an isolated RS-232
interface**.

This document assumes the user is familiar with the MODBUS® protocol and its terminology.

Please refer to the documents listed in the References section for more information.

MODBUS® is a registered trademark of Modbus-IDA (www.modbus-ida.org)

Parameters

The SunSaver MPPT supports RTU mode only.
16bit MODBUS® addresses (per the modbus.org spec)
The serial communication parameters are
? BPS: 9600 baud
? Parity: None
? Data bits: 8
? Stop bits: 2
? Flow control: None
All addresses listed are for the request PDU.

The SunSaver MPPT default server address: 0x01.
Supported MODBUS® Functions
Read Holding Registers (0x03) and Read Input Registers (0x04)
RAM
PDU
Addr
Logical
Addr
Variable name Variable description Units Scaling or Range
0x0008 9 Adc_vb_f Battery voltage, filtered (? ? 1s) V n·100·2-15
0x0009 10 Adc_va_f Array voltage, filtered (? ? 1s) V n·100·2-15
0x000A 11 Adc_vl_f Load voltage, filtered (? ? 1s) V n·100·2-15
0x000B 12 Adc_ic_f Charging current, filtered (? ? 1s) A n·79.16·2-
15
0x000C 13 Adc_il_f Load current, filtered (? ? 1s) A n·79.16·2-
15
0x000D 14 T_hs Heatsink temperature ºC -128 to
+127
0x000E 15 T_batt Battery temperature (Either ambient or RTS if
connected)
ºC -127 to
+127
0x000F 16 T_amb Ambient temperature ºC -127 to
+127
0x0010 17 T_rts Remote battery temperature sensor (0x80 if not ºC -127 to
connected) +127
0x0011 18 charge_state Charge state -
0x0012 19 array_fault Array fault bitfield -
0x0013 20 Vb_f Battery voltage, slow filter (? ? 25s) V n·100·2-15
0x0014 21 Vb_ref Battery regulator reference voltage V n·96.667·2-
15
0x0015 22 Ahc_r_HI Ah charge resetable, HI word Ah n·0.1
0x0016 23 Ahc_r_LO Ah charge resetable, LO word -
0x0017 24 Ahc_t_HI Ah charge total, HI word Ah n·0.1
0x0018 25 Ahc_t_LO Ah charge total, LO word -
0x0019 26 kWhc kWh charge (resetable?) kWh n·0.1
0x001A 27 load_state Load state -
0x001B 28 load_fault Load fault bitfield -
0x001C 29 V_lvd load current compensated LVD voltage V n·100·2-15
0x001D 30 Ahl_r_HI Ah load resetable, HI word Ah n·0.1
0x001E 31 Ahl_r_LO Ah load resetable, LO word -
0x001F 32 Ahl_t_HI Ah load total, HI word Ah n·0.1
0x0020 33 Ahl_t_LO Ah load total, LO word -
0x0021 34 hourmeter_HI hourmeter, HI word h 0 to (224-1)
0x0022 35 hourmeter_LO hourmeter, LO word -
0x0023 36 alarm_HI alarm bitfield – HI word -
0x0024 37 alarm_LO alarm bitfield – LO word -
0x0025 38 dip_switch dip switch settings at power on
switch[1..8] in bits[0..7]

0x0026 39 led_state SOC LED state -
0x0027 40 Power_out Charge output power W n·989.5·2-
16
0x0028 41 Sweep_Vmp Array Vmp found during sweep V n·100·2-15
0x0029 42 Sweep_Pmax Arrap Pmax(output) found during sweep W n·989.5·2-
16
0x002A 43 Sweep_Voc Array Voc found during sweep V n·100·2-15
0x002B 44 Vb_min_daily Vb minimum voltage – daily V n·100·2-15
0x002C 45 Vb_max_daily Vb maximum voltage – daily V n·100·2-15
0x002D 46 Ahc_daily Ah charge - daily Ah n·0.1
0x002E 47 Ahl_daily Ah load - daily Ah n·0.1
0x002F 48 array_fault_daily Array fault bitfield - daily -
0x0030 49 load_fault_daily Load fault bitfield - daily -
0x0031 50 alarm_HI_daily alarm bitfield – daily, HI word -
0x0032 51 alarm_LO_daily alarm bitfield – daily, LO word -
0x0033 52 vb_min minimum battery voltage V n·100·2-15
0x0034 53 vb_max maximum battery voltage V n·100·2-1
0x0039 58 va_ref_fixed fixed Vmp if set (overrides % if both set) V n·100·2-15
0x003A 59 va_ref_fixed_pct Vmp = % of Voc if set (0 or 0xff disables) % n1002-8

1 Due to MODBUS® message length limits, it is unlikely that all 128 points of sweep data can be returned in
one request. Request sweep data in two separate requests.

I suspect before buying hardware, you should write a program on your PC that can read two serial lines and displays the data you want in a format that would be similar to the LCD you plan on using. Write this in C or C++ and not higher level languages like perl/python/etc. This will tell you if it is doable. After that, I would buy an UNO, and see if it can handle the flow. If it does, you can then look at custom PCB parts using an AVR chip so you can get the cost down for the finished product.

If the UNO can't keep up, you probably need to step up to an arm. I tend to think the tweeny 3.0 which has multiple UARTs might keep up with really fast streams, and it has hardware floating point. Hardware serial ports tend to support signalling when they are ready to read data, so it is less likely you might have dropped data, which is important if the device just sends a full status report every minute or so. Obviously if there is a command to send just the data you are interested in rather than a summary of the entire machine state, that can speed things up.

There are many other ARM solutions, but you would probably need to carefully read the data sheet of the particular ARM chip involved. Even so, the most power reduced ARM is probably an order of magnitude faster than the AVR. Again, like with the UNO, you might start with a more expensive development kit, and then once you have a proof of concept, refine the design so it is cheaper and easier to manufacturer.

By the look of it, that modbus protocol is a request and respond protocol i.e. your arduino will need to ask the device for data. Given that and the slow 9600 baud rate, I would expect that an uno can handle it easily. Further, if you're displaying data on an LCD, you won't want it changing particularly frequently or the users won't be able to read it.

wildbill:
By the look of it, that modbus protocol is a request and respond protocol i.e. your arduino will need to ask the device for data. Given that and the slow 9600 baud rate, I would expect that an uno can handle it easily. Further, if you're displaying data on an LCD, you won't want it changing particularly frequently or the users won't be able to read it.

I was thinking that the data had to be requested via Modbus to get the data sent back so its good that we can only request that data that I want displayed.

The other device (Victron Battery Monitor) outputs data via a TTL.

?The serial port is accessed via the 4-pin header located on the rear of the BMV.

Pin Function #1 3.3 - #2 BMV-TX - #3 BMV-RX - #4 GND

The signals on the BMV serial link are non-isolated 3.3V logic levels.

Can the Audrino accept serial data output directly from these 4 pins that output data via TTL?

Message format
The BMV transmits blocks of statistics in 1 second intervals. Each statistic uses the following format:

The identifiers are defined as follows:

Identifier Meaning

A carriage return followed by a line feed (0x0D, 0x0A).
An arbitrary length label that identifies the statistic. Where applicable, this will be
the same as the label that is used on the LCD.
A horizontal tab (0x09).
The ASCII formatted value of this statistic. The number of characters transmitted
depends on the magnitude and sign of the value.

Data integrity

The statistics items are grouped in blocks with a checksum appended. The last statistic in a block will
always have the label “Checksum”. The value of this statistic is a single byte, and will not necessarily
be a printable ASCII character. The modulo 256 sum of all bytes in a block will equal 0 if there were
no transmission errors. Multiple blocks are sent containing different statics.

MichaelMeissner:
I suspect before buying hardware, you should write a program on your PC that can read two serial lines and displays the data you want in a format that would be similar to the LCD you plan on using. Write this in C or C++ and not higher level languages like perl/python/etc. This will tell you if it is doable. After that, I would buy an UNO, and see if it can handle the flow. If it does, you can then look at custom PCB parts using an AVR chip so you can get the cost down for the finished product.

If the UNO can't keep up, you probably need to step up to an arm. I tend to think the tweeny 3.0 which has multiple UARTs might keep up with really fast streams, and it has hardware floating point. Hardware serial ports tend to support signalling when they are ready to read data, so it is less likely you might have dropped data, which is important if the device just sends a full status report every minute or so. Obviously if there is a command to send just the data you are interested in rather than a summary of the entire machine state, that can speed things up.

There are many other ARM solutions, but you would probably need to carefully read the data sheet of the particular ARM chip involved. Even so, the most power reduced ARM is probably an order of magnitude faster than the AVR. Again, like with the UNO, you might start with a more expensive development kit, and then once you have a proof of concept, refine the design so it is cheaper and easier to manufacturer.

Yes initially the larger Uno boards are fine but I would like to keep this as small as possible since alot of the systems I build have very little room inside the case for extra parts.

Currently I do not need high quantity so just building them as needed is fine for now so I do not anticipate ever designing a special board just for this task. The Digispark looks killer but the Tweeny 3 looks great also, either would work I just prefer the smallest solution possible.

No I just have to figure out if I can use simple wires from the equipments data output port to the regular serial input ports on the Audrino without the need of any additional adapters. If so then all I need is to pay a software person to do all that which I have no clue how to do. I just know what I want to end up with once its all working.

Thanks again for the help!