I figured this deserves a thread of its own.
What would you like to see in a "Black Box" as brought up in the Local App on a Samsung Tablet thread:
http://midnitesolar.com/smf_forum/index.php?topic=1070.0 (http://midnitesolar.com/smf_forum/index.php?topic=1070.0)
Lets hash out what folks would like to see this device do.
How could it be useful to you?
What devices other than the Classic should it be able to interface with?
Just toss it out there and we will see what sticks to the wall.
Thoughts, ideas, whatever.
Tom
Cheap, naturally
Low power requirement. 5, 9 or 12 v dc
USB connection to a rPi/PC/Netbook, etc
Linux, MS, Mac Op system
stand alone, programmable for polling time interval 1 min to 1 hr
~ 750 days storage of all data min.
Open Source
more later...
westbranch;
Power wise, the standard for low power devices seems to be 5 volts USB type power supplies so
that seems the way to go.
Ethernet, USB connectivity. Covers storage (USB stick) and communication (USB serial & ethernet)
Stand alone, certainly.
Programming flexibility. Absolutely. Already exists with a Pi.
Platform independent web browser based user interface for sure.
Pretty sure we are on the same page so far.
Tom
I sort of like the idea of a box that gathers data from one or more classics , maybe clipper, battery monitor and perhaps other useful devices such current and voltage detectors at various places, detects open breakers and fuzes ( I don't know how this would be done ) and coordinates it all into a general system report web pages.
I am already biased towards the RPi buts its lack of modbus support is disturbing..
Dgd
Quote from: dgd on March 06, 2013, 11:55:46 PM
I sort of like the idea of a box that gathers data from one or more classics , maybe clipper, battery monitor and perhaps other useful devices such current and voltage detectors at various places, detects open breakers and fuzes ( I don't know how this would be done ) and coordinates it all into a general system report web pages.
I am already biased towards the RPi buts its lack of modbus support is disturbing..
Dgd
A CAI Webcontrol could gather info on things like switch or breaker states by reading across the switch / breaker looking for voltage (open switch =voltage on leads). It can do Analog to Digital conversion to sense voltages, measure shunts with some circuitry I know already exists. It has a proprietary system on it including a web based programming and monitoring system programmed in PLC. Not sure if or how it could be reprogrammed for this project? In concert with a Pi it could extend the capabilities of a Pi but would likely double the hardware costs. The Webcontrol can send emails on fault conditions like open breakers, high or low voltage and combinations of data Could always have optional components to extend functionality of the basic system, of course.
I have other ideas but its about my bedtime for tonight.
Tom
Quote from: TomW on March 07, 2013, 12:21:20 AM
A CAI Webcontrol could gather info on things like switch or breaker states by reading across the switch / breaker looking for voltage (open switch =voltage on leads). It can do Analog to Digital conversion to sense voltages, measure shunts with some circuitry I know already exists. It has a proprietary system on it including a web based programming and monitoring system programmed in PLC. Not sure if or how it could be reprogrammed for this project? In concert with a Pi it could extend the capabilities of a Pi but would likely double the hardware costs. The Webcontrol can send emails on fault conditions like open breakers, high or low voltage and combinations of data Could always have optional components to extend functionality of the basic system, of course.
I have other ideas but its about my bedtime for tonight.
Tom
Tom,
Cool ideas!
I'm currently working on a system to more accurately monitor my AC and DC currents, battery voltage, temp, etc. The accuracy and resolution limitations on the Outback equipment (Inverter and FNDC) is frustrating. I've thought about a device that could then use this info to implement some control (loads, end absorb, etc) as well as log data to a user friendly interface.
I'm looking at the possibility of an Arduino, rPi combo.... we'll see...
I'm just now experimenting with different current sensors (CTs and Hall effect) as well as using my existing 50 mv/ 500 amp shunt. One issue to keep in mind is that the ADC resolution (typically 8 bit or less) in many existing low cost DAQ devices (eg Arduino) is not adequate for measuring the tiny- millivolt range voltages across shunts. I'm experimenting with a 24 bit ADC IC now.
Just a heads up if looking at a CAI Webcontrol type device for shunt voltage measurements - it will need 16 bit ADC or better I think...
Quote from: mtdoc on March 07, 2013, 03:38:02 PM
One issue to keep in mind is that the ADC resolution (typically 8 bit or less) in many existing low cost DAQ devices (eg Arduino) is not adequate for measuring the tiny- millivolt range voltages across shunts.
Just a heads up if looking at a CAI Webcontrol type device for shunt voltage measurements - it will need 16 bit ADC or better I think...
There is a circuit that can be built on a breakout board for the Webcontrol that uses an op amp to boost shunt voltages to the proper levels for the built in ADC. I have not done it myself but rumor is that it works.
Waiting for some hardware to get this moving forward. It should be interesting.
I looked at the Aurdino but by chance ended up with a Pi so that is what I have to mess with now.
Tom
Quote from: TomW on March 07, 2013, 03:56:51 PM
There is a circuit that can be built on a breakout board for the Webcontrol that uses an op amp to boost shunt voltages to the proper levels for the built in ADC. I have not done it myself but rumor is that it works.
Waiting for some hardware to get this moving forward. It should be interesting.
I looked at the Aurdino but by chance ended up with a Pi so that is what I have to mess with now.
Tom
More options!
As I'm learning, the Arduino and rPi are more complementary than alternatives. I'm just getting up to speed on both so I'm not sure how it will all pan out. I can use the Arduino (or bare Atmel chip) as an I/O, ADC interface between sensors and computer. (sounds like the CAI device could do likewise - as could a Gertboard). The question is what computer. I can use Labview on a mac or windows pc with Arduino to program a nice logging and control user interface but ultimately using the rPi as the computer would be a much lower cost, lower power (and cooler!) alternative. Dunno much about Python though.... :-\
The sensors connecting to this box have been my interest for the last few months. These are mostly current sensors as I want to get some accurate readings of amps produced and consumed by the different devices.
The 500amp shunt in the MNDC looks like it needs at least a 14bit AtoD device to give 0.1amp resolution over a -400A to +400A range of readings. Such devices are readily available and quite low cost. Available on Arduino interface cards. And there often is instructions,coding examples to drive then, sometimes via an RPi.
I see it as only a short step to then use data from this shunt, clocked and stored, to create an accurate but basic battery monitor. In conjunction with charge stage control inputs to the Classic, preferably via AUX input, there would be everything needed to deal with LiFeYPO4 batteries.
The previous threads on the accuracy of volt and amps as displayed by the Classic have raised the need for some good measurements external to the Classic. Again current in and out 150 amp shunts to measure 0 to 100 amps. 11 bit A to D here would suffice. I have also thought about amps readings for each PV string (I have 4)
..more later..
dgd
Tom,
How far did you get with the Rpi using the USB serial port connection to the Classic? Did boB get any more commands set up to
provide more config or reporting capability?
dgd
Quote from: dgd on March 12, 2013, 03:26:01 AM
Tom,
How far did you get with the Rpi using the USB serial port connection to the Classic? Did boB get any more commands set up to
provide more config or reporting capability?
dgd
dgd;
I have been logging from it for a long while and quite successfully. I have updated the Classic and MNGP with it. I have not bugged boB for more serial port options because they were pretty busy with the Local App upgrades.
Now that I have an associate involved I expect to push boB for more technical information. I have been down with a rotator cuff injury since December and just don't get much done beyond what is absolutely necessary to get by. That is coming along nicely and full recovery is imminent so I will get back to more work on the Pi soon.
So minimal progress.
OK, boB, time to bug you for documentation on the serial capabilities and commands, I guess.
Tom
Quote from: TomW on March 12, 2013, 10:22:00 AM
Quote from: dgd on March 12, 2013, 03:26:01 AM
Tom,
How far did you get with the Rpi using the USB serial port connection to the Classic? Did boB get any more commands set up to
provide more config or reporting capability?
dgd
dgd;
I have been logging from it for a long while and quite successfully. I have updated the Classic and MNGP with it. I have not bugged boB for more serial port options because they were pretty busy with the Local App upgrades.
Now that I have an associate involved I expect to push boB for more technical information. I have been down with a rotator cuff injury since December and just don't get much done beyond what is absolutely necessary to get by. That is coming along nicely and full recovery is imminent so I will get back to more work on the Pi soon.
So minimal progress.
OK, boB, time to bug you for documentation on the serial capabilities and commands, I guess.
Tom
I will look but I think you are going to be disappointed. There ain't much there right now.
I am going to add stuff like reading the EEprom etc.
Yeah, that's about all that's there right now. No unix shell or cool stuff like that...
That would be pretty neat though... How about Classic DOS ?
boB
Well, folks, Ross has been hammering on pieces of this project and has had some good progress happening.
He has built an application to poll the Classic over ethernet. It compiled out of the box on my Raspbian Pi and my Ubuntu 11.10 laptop. It uses no proprietary software or external libraries.
It can poll a list of registers and has primitives included for values that must be massaged for presentation.
Sample raw output:
./newmodbus 192.168.2.129 4115-4118/10 4119 4121-4122/10 4125/10 4132-4134/10 4120\>8
ID �<< this will be the name you assigned the Classic but has a bug that displays it incorrectly.
4115 = 26.3
4116 = 86.4
4117 = 16.4
4118 = 0.7
4119 = 434 (0x1B2)
4121 = 5.1
4122 = 104.9
4125 = 2.7
4132 = 21.1
4133 = 47.7
4134 = 51.0
4120 = 4
it returns the processed register data lightning fast and blows away the USB dump method on accuracy and speed.
You can see where he has gone with a webpage for the Classic data here:
http://ranges.albury.net.au/midnight/classic.shtml (http://ranges.albury.net.au/midnight/classic.shtml)
Hover over the values to see historic data graphed.
Just some progress on the project. Getting the data via TCP/IP was the first step.
If anyone is interested in messing with it I can pass on the binary for either ARM or i686 / i386 Linux. Just Pm me your email and I will send it along. The code is not ready for passing on yet but probably will be when he sorts out some issues.
Tom
Quote from: TomW on May 22, 2013, 11:07:21 AM
Well, folks, Ross has been hammering on pieces of this project and has had some good progress happening.
He has built an application to poll the Classic over ethernet. It compiled out of the box on my Raspbian Pi and my Ubuntu 11.10 laptop. It uses no proprietary software or external libraries.
It can poll a list of registers and has primitives included for values that must be massaged for presentation.
Sample raw output:
./newmodbus 192.168.2.129 4115-4118/10 4119 4121-4122/10 4125/10 4132-4134/10 4120\>8
ID �<< this will be the name you assigned the Classic but has a bug that displays it incorrectly.
4115 = 26.3
4116 = 86.4
4117 = 16.4
4118 = 0.7
4119 = 434 (0x1B2)
4121 = 5.1
4122 = 104.9
4125 = 2.7
4132 = 21.1
4133 = 47.7
4134 = 51.0
4120 = 4
it returns the processed register data lightning fast and blows away the USB dump method on accuracy and speed.
Should have checked your mail first, Tom :) Sent you the fixed code 20hrs and 3 mins ago :)
% ./classicmodbus `cat classic.addr` 4115-4118/10 4119 4121-4122/10 4125/10 4132-4134/10
ID Solar2
4115 = 49.4
4116 = 90.4
4117 = 24.0
4118 = 0.8
4119 = 1192.0
4121 = 13.4
4122 = 127.0
4125 = 1.7
4132 = 23.5
4133 = 45.5
4134 = 47.8
And setting the device name is a snap:
% ./classicmodbus `cat classic.addr` 4210='CLASSIC'
ID Solar2
% ./classicmodbus `cat classic.addr` 4210-4213
ID CLASSIC
4210 = 19523 (0x4C43)
4211 = 21313 (0x5341)
4212 = 18771 (0x4953)
4213 = 67 (0x43)
And it's reasonably quick:
% time ./classicmodbus `cat classic.addr` 4210-4213
ID CLASSIC
4210 = 19523 (0x4C43)
4211 = 21313 (0x5341)
4212 = 18771 (0x4953)
4213 = 67 (0x43)
real 0m0.018s
user 0m0.000s
sys 0m0.001s
Please make no mistake - this isn't intended to be a replacement for the localapp, it's a low-level, command-line tool to get data out of the classic for logging, monitoring and alarms. It's lightweight, portable and fast and flexible. Intended to be used in scripts or with some sort of wrapper. Well, that's the plan - who knows what it'll morph into as people like Tom get their claws into it. "Feature-creep" already happened with writing, so anything's possible.
Ross;
I must have missed that email?
Tom
Quote from: TomW on May 22, 2013, 07:02:13 PM
I must have missed that email?
I'll resend it now - but will catch you in IRC.
Ross,
Have you written or adopted some C code for this modbus reader? And compiled it on the rPi?
Or is it interpreted code of some sort?
Although you say it's not intended to replace the local app, your program with parameter input on command line is ideal for shell scripting, I would actually like to see a web page that replaces the local app, at least the live metering part.
To this end I have several C functions that implement the multiple register read and write commands and have used these to create a date update program for the classic lite.
My ongoing project now is getting a live web page that shows a continuous changing of the basic classic volts,amps,watts,energy,temp readings.
And in a skinned type graphical dashboard.
Including reporting in this is not my goal as after event reporting can be handled by many available graphing packages.
Anyway, you have made good progress, good to see. :)
Dgd
Quote from: dgd on May 23, 2013, 12:31:49 AM
Ross,
Have you written or adopted some C code for this modbus reader?
Written in straight C from scratch, no copied, borrowed or GPL (etc). All my own original work, so unencumbered!
Quote
And compiled it on the rPi?
I developed locally under FreeBSD, sent the source and virtually no instructions apart from "cc -o modbus modbus.c" to TomW, who compiled on one of his boxes and then later on one of his pi's.
Quote
Or is it interpreted code of some sort?
Although you say it's not intended to replace the local app, Andrew your program with parameter input on command line is ideal for shell scripting, I would actually like to see a web page that replaces the local app, at least the live metering part.
To this end I have several C functions that implement the multiple register read and write commands and have used these to create a date update program for the classic lite.
My ongoing project now is getting a live web page that shows a continuous changing of the basic classic volts,amps,watts,energy,temp readings.
And in a skinned type graphical dashboard.
Including reporting in this is not my goal as after event reporting can be handled by many available graphing packages.
Anyway, you have made good progress, good to see. :)
I already log, and display "near-real-time" (only updated every 300 seconds - but that's entirely for other reasons, could be constantly updated if you wanted).
A VERY clunky PoC (just so I could see it on my mobile phone) is as Tom posted earlier: http://ranges.albury.net.au/midnight/classic.shtml
Yes, scripting things with it is the purpose.
It currently writes to registers using the = (assign) primative.
It'll write a string or an integer - so formatting to take time is easy enough to do, but messy. I'm going to add a switch (perhaps -ts?) to automatically time-sync the midnite to local clock.
I've been tinkering with my own 'black box' interface to my classic lite (https://netduinosolar.codeplex.com/), I have an arduino shield that includes a real time clock and I was hopping to set the classic lite date-time. I unlocked the classic by writing the serial# to register 20492, then wrote the date-time to registers 4214 - 4218. The write succeeds but the classic time remains at 2003...
I was wondering if anyone would share a code snippet that demonstrates how to set the date-time on a classic-lite.
thanks
Graham.
Time in 4213 (16bit integer 0 to 15360 incrementing counter for an hour with value/256 for minute count and remainder/256*60 for seconds) and 4214 (byte day of week but I'm not sure it is, byte hour, date in 4125 (byte day byte month) and 4216 is 16 bit year. ???
I don't think 4217 and 4218 are involved but I'm usually wrong...
I will get the c routine I wrote for this and post later.
Dgd
Quote from: rossgr on May 25, 2013, 01:40:16 PM
I've been tinkering with my own 'black box' interface to my classic lite (https://netduinosolar.codeplex.com/), I have an arduino shield that includes a real time clock and I was hopping to set the classic lite date-time. I unlocked the classic by writing the serial# to register 20492, then wrote the date-time to registers 4214 - 4218. The write succeeds but the classic time remains at 2003...
I was wondering if anyone would share a code snippet that demonstrates how to set the date-time on a classic-lite.
I just got to that part of my own code today... and have encountered the same problem. Even with the "LOCK" jumper in the unlocked position. I'm pretty sure my code is right too, looking at the bytes being actually sent:
% ./classicmodbus -td `cat classic.addr`
ID Solar2
Classic Time 10:14:44 26/05/2013
System Time 10:15:15 26/05/2013
Write 00 02 00 00 00 0f ff 10 10 75 00 04 08 0f 0f 00 0a 05 1a 07 dd
Read 7 (header) bytes: 0 2 0 0 0 6 ff
So lets strip off the tcp encapsulation, look only at the relevant modbus bits:
10 10 75 00 04 08 0f 0f 00 0a 05 1a 07 dd
10 - "write multiple registers".
1075 -> 4213 decimal = (4214-1) = correct starting register.
0004 -> 4 registers to write.
08 -> 8 bytes to send. (4 x 16-bit registers = 8 bytes)
now comes the messy stuff. 0f0f000a should be the "time", per the structure provided.
I'm using a structure, rather than bit shifting and masking - not sure it's any easier, but it's tidier, and self-documents the code.
typedef union
{
struct
{
unsigned int sec : 6; // bits 5-0 are seconds
unsigned int void1 : 2; // unused
unsigned int min : 6; // bits 13-8 are minutes
unsigned int void2 : 2; // unused
unsigned int hrs : 5; // bits 20-16 are hours
unsigned int void3 : 3; // unused
unsigned int dow : 3; // bits 26-24 are day-of-week
unsigned int void4 : 5; // unused
}time;
struct
{
unsigned int day : 5; // bits 4-0 are day of month
unsigned int void1 : 3; // unused
unsigned int month : 4; // bits 11-8 are month
unsigned int void2 : 4; // unused
unsigned int year : 12; // bits 27-16 are hours
unsigned int void3 : 4; // unused
}date;
unsigned int raw;
}classictime;
so 0f0f000a should be read as 000a0f0f when re-assembled
0000000000001010.0000111100001111
breaking into logical bitwise fields
xxxxx000xxx01010.xx001111xx001111
^^^^^-- 15 seconds
^^^^^------------- 15 minutes
^^^^-------------------------- 10 hours
^^^------------------------------------ day 0 (sunday)
That's exactly what it should have been: System Time 10:15:15 26/05/2013
Doing the same thing with the date:
05 1a 07 dd -> 07dd051a = 0000011111011101.0000010100011010
xxxx011111011101.xxxx0101xxx11010
^^^^--- 26 days
^^^-------------- 05 month
^^^^^^^^^-------------------------- 2013 year
Which is also correct... only thing I haven't done is set the day-of-year. Not sure that's even important but I'll try it.
.... ok, back (did you blink?).
Changed to send 10 bytes (not 8), and included setting the "day-of-year", but still ignoring me.
I think we need Bob or Andrew to advise on this one!
Hi guys...
I stumbled onto this just now.
As you know, I am updating the modbus document and I've found the problem
which is a bit of an error in the doc.
You're probably not going to like it though.
The doc says Write Only. Well, these 3 CTIME (Consolidated Time) Registers
are actually Read Only. You have to set the Classic's time and date through
file transfer at the moment which I am adding to the documentation.
Since file transfer is a bit harder to deal with than just reading or writing
registers, I think I will either add separate registers for Sec, Min, DOM, Year, etc.
Sorry you've wasted your time here but at least now we know why it did not work.
boB
From the manual....
6.3 Consolidated time registers
The values of the Time Counters can optionally be read in a consolidated format which
allows the programmer to read all time counters with only three read operations. The
various registers are packed into 32 bit values as shown in Table 26â€"507, Table 26â€"508,
and Table 26â€"509. The least significant bit of each register is read back at bit 0, 8, 16, or
24.
The Consolidated Time Registers are read only. To write new values to the Time
Counters, the Time Counter addresses should be used.
boB,
So how is the MNGP writing the current date and time to the Classic? If its not writing to modbus registers is there a serial port command that it uses to set time and date?
Why not just make the time/date modbus registers writeable? Does it really matter what the docs say? There is likely a r/o or r/w flag or mode table for the modbus registers
Dgd
Quote from: dgd on May 26, 2013, 04:39:53 AM
boB,
So how is the MNGP writing the current date and time to the Classic? If its not writing to modbus registers is there a serial port command that it uses to set time and date?
Why not just make the time/date modbus registers writeable? Does it really matter what the docs say? There is likely a r/o or r/w flag or mode table for the modbus registers
Dgd
The MNGP presently uses modbus file transfer to set the time registers because it also sets the sunrise and sunset from
the earlier wizard.
I will add registers to set time/date with and then you will have to set a Force Flag to actually transfer the values
to the timer.
boB
Quote from: boB on May 26, 2013, 03:23:49 PM
I will add registers to set time/date with and then you will have to set a Force Flag to actually transfer the values
to the timer.
Not sure any of us particularly mind how it's done, if it's clearly documented so we can do it :)
Thanks for the responses, look forward to seeing the updated docs.
There are probably bits of this thread/discussion scattered across the forum.
Trying to pull it back into one place if I can!
For those who wanted to try it, here are precompiled binaries of the current version:
http://support.rossw.net/midnite/newmodbus.PI (http://support.rossw.net/midnite/newmodbus.PI) for Raspberry Pi with Raspbian on it.
http://support.rossw.net/midnite/newmodbus.PC (http://support.rossw.net/midnite/newmodbus.PC) for Ubuntu 11.10
http://support.rossw.net/midnite/newmodbus.OSX (http://support.rossw.net/midnite/newmodbus.OSX) for Mac OS/X
This version doesn't autodiscover classics, it requires you to tell it the IP address.
Once downloaded, run it like this:
./newmodbus -p 192.168.1.63 (whatever your classic IP address is)
Solar2 Display Panel 1.0.13, RossW
State BulkMppt
Firmware 1401
ClassicTime 13:27:04 10/06/2013
759 Watts out
50.4 Volts (Battery)
102.9 Volts (PV)
15.0 Amps (Battery)
5.5 kWh today (100 amphours)
Quote from: RossW on June 09, 2013, 11:36:42 PM
For those who wanted to try it, here are precompiled binaries of the current version:
I've updated the code - under some conditions one of the buffers was overrunning while sending data.
HI Guys,
I have ross's newmodbus running on my web dev server, which is a 2year old dual core atom so it draws 19W (that's well due for a rebuild (waiting for silvermount)). Given this is as much as the fridge ive ordered a cubieboard, and will run in on that for now. However it got me thinking about the pending release of the battery monitor addon and how the black box idea would be ideal for every classic owner that doesnt have access to a inverter or flexnet based monitoring system.
Options :
- arm dev board with a case
- ready made hackable version of above, eg mele
http://dx.com/p/mele-a2000-1080p-android-2-3-network-multi-media-player-w-sata-usb-hdmi-lan-vga-wifi-4gb-131566
- cheap tablet, over wifi, or ethernet over usb
For my 2c browser viewable is enough. Or if people wanted a small LCD or something like that, i guess there'd be options. rPi folk would know.
All sorts of options, but mele does seem like a cheap easy solution to me.
Im happy to share my UI code, when its done, but those of interested could, like, cooperate.
Quote from: zoneblue on July 26, 2013, 02:29:25 AM
HI Guys,
I have ross's newmodbus running on my web dev server, which is a 2year old dual core atom so it draws 19W (that's well due for a rebuild (waiting for silvermount)). Given this is as much as the fridge ive ordered a cubieboard, and will run in on that for now. However it got me thinking about the pending release of the battery monitor addon and how the black box idea would be ideal for every classic owner that doesnt have access to a inverter or flexnet based monitoring system.
Options :
- arm dev board with a case
- ready made hackable version of above, eg mele
http://dx.com/p/mele-a2000-1080p-android-2-3-network-multi-media-player-w-sata-usb-hdmi-lan-vga-wifi-4gb-131566
- cheap tablet, over wifi, or ethernet over usb
For my 2c browser viewable is enough. Or if people wanted a small LCD or something like that, i guess there'd be options. rPi folk would know.
All sorts of options, but mele does seem like a cheap easy solution to me.
Im happy to share my UI code, when its done, but those of interested could, like, cooperate.
Does the mele have a Real Time Clock? I had to build a custom shield that included an RTC for my netduino based monitor so I could log data from a classic lite which doesn't have a clock.
So is that your stuff at https://netduinosolar.codeplex.com/ ?
AFAIK all arm A10 based baords have RTCs. If its like the cubie it has no battery, but you can keep the clock current with ntp as you would on any server.
I know rPi has big community support and is well estabished but mele / beagle / Cubieboard as an example has 1Gb RAM 4GB on board flash, and best of all sata.
With the simple addtion of a 2.5" ssd, notably the samsung 840 series which have 40mW idle draw, you have fairly capable debian server that draws around 1 or 2 watts. That to me is a game changer.
Hey i just noticed Ryan started a new area open source, shall we adjorn over there?
Quote from: zoneblue on July 26, 2013, 04:31:02 PM
So is that your stuff at https://netduinosolar.codeplex.com/ ?
AFAIK all arm A10 based baords have RTCs. If its like the cubie it has no battery, but you can keep the clock current with ntp as you would on any server.
I know rPi has big community support and is well estabished but mele / beagle / Cubieboard as an example has 1Gb RAM 4GB on board flash, and best of all sata.
With the simple addtion of a 2.5" ssd, notably the samsung 840 series which have 40mW idle draw, you have fairly capable debian server that draws around 1 or 2 watts. That to me is a game changer.
Hey i just noticed Ryan started a new area open source, shall we adjorn over there?
Yes, it's been running at my off grid cabin for several months now, I don't have access to the internet there which is why I need an RTC.