Analog Input circuitry.

[rossw]

Ross,

You got more than 12 hours generation in summer there, that is really good. Don't know if your tracker also track the sun elevation, which changes a lot between 6/23 and 12/23.

Yes, we get a fair bit of sun here in summer. My arrays are single-axis tracking, but the second axis is easily adjusted seasonally.
It makes a fairly significant difference to the output so I adjust it every couple of months.

You could have TTL output to control which analog input to read, by using only one A/D input with IC like this:
http://www.analog.co...ts/product.html
or
http://www.analog.co...ts/product.html

I looked at doing that initially. I was going to use 4053 because I have hundreds of them on hand. But they, like the ADG5233 you suggested, have fairly high "on" resistance (given they claim "low on resistance of 160 ohms typical") - and I am unsure how they'd work at the millivolt input range. So the option was to put them after the amplifiers, which means I was trading another ADC for the 4053 and its control circuitry, and that would still only give me 6 channels (remember I asked about accessing the raw count of the 4th channel - humidity?). I need 7 channels, so double-mux would be necessary. A lot of messing about, and it would make a board that was a single use only. The way I did it makes a flexible board others may want to use also.

The WebControl internal logic actually do over sampling, so that A/D resolution is more like 12bit. You do need to adjust R10 to get A/D noise to 0. The best value for R10 is 2.26K, however, your board may be between 2.0K to 2.4K to get the optimal zero noise level. All current shipping board already have the R10 value adjusted to near zero.

Yes, It's on my list of things to do.

You could make a product by providing tracking control to people. From your chart, your solar arrays produce twice more than those fix mounted panels.
If you need any help, we will definitely work with you.

I have already sent controllers and code to some associates in Iowa and Texas in the USA, and other parts of Australia. The webcontrol board is lacking some functions that would be really helpful - for example, look-up tables or trig functions. (Since trig would require floating point, that's out. But some LUT functionality would be REALLY great. I'd propose defining a LUT, then adding a new command to read an index from it. This would let us create some really cunning code, including some crude trig functions!)

About half my total code at the moment is simply ugly compares to estimate the sunrise and sunset times for "today" that could be done in a couple of lines of LUTs or trig functions.

 

[fwd03]

Ross,

ADG1612 spec says its on resistence is 1 Ohm.
Depending on what do you measure, if measuring voltage, there is not much current, so the on resistence would not make much difference anyway.

For example, the ADC input after modify to 5V full scale, its input resistence is still 46K or so at full 5V, 130Ohm is about 0.28%.

 

[MobileMe]

A system I wrote many years ago. It logs, graphs and alarms something like 920 conditions (not just WC boards).

Would you consider releasing what you wrote? I would love to have the ability to graph some stats from the board.

 

[CAI_Support]

Hi Ross,

There is no trigonometry function in this micro. However, adding ROM LUT is possible, if not using any RAM. CRC16 and CRC8 are both LUT based calculation.
What kind of LUT you are talking about? If it is in ROM, user will not be able to define, we will have to program it into ROM in the factory. If you could provide some details, we will see how can we best fit them in.

 

[rossw]

Hi Ross,

There is no trigonometry function in this micro. However, adding ROM LUT is possible, if not using any RAM. CRC16 and CRC8 are both LUT based calculation.
What kind of LUT you are talking about? If it is in ROM, user will not be able to define, we will have to program it into ROM in the factory. If you could provide some details, we will see how can we best fit them in.

If it has to be ROM only it will be far less useful. The only "universal" LUT I could imagine would be of any use would be probably sin(x). Radians would make no sense in this context, but integer degrees from 0 to 90 might do, return a scaled number. Since 0-255 wouldn't be much good, a 16-bit value could easily return 0-9999 (representing 0-0.9999), and we would have to scale the answer in our code.

I could see however far more use for variable sized user-defined LUTs. Eg, a table of sunrise times. Often, these tables are fairly small (12 months, 31 days, 7 days) or a table of offsets or setpoints - eg, temperatures (perhaps 8 or 16).

If I assume your PLC code occupies a minimum of 1 byte per instruction (or could be several bytes, eg "mul ram1 123456789 ram2" I dare say is at least 5 bytes long), then using "program" space for LUTs wouldn't take any "more" resources and would let the programmer make the trade-off.

example:

	 lut 1 31,29,31,30,31,30,31,31,30,31,30,31
...
...
    set ram1 lut[1][CMONTH]		 # set ram1 to number of days this month

 

[CAI_Support]

If we can fetch that sun rise and sun set data from public web servers, that is probably easier for you. But we are working hard on fetch VAR back due to Microchip TCP stack would not reassemble data -- which is undersandable, since some TCP reply could be 2000 bytes, with total RAM 3808, there is no way TCP stack can do anything by default. We have to manually patch up the reply from servers, and useful reply might be break into two packets, in addition, different server and different CGI can have totally different reply.

Another problem would be, if fetch from external server failed for any reason, that could ruin all your logic.

CRC16 lookup table has 256 two bytes number like 0x1234 or 0xFEDC. To store another LUT in ROM like that is not hard. If you only need one degree resolution, 90 degree will only has 90 values. We will need more information then work on that for you.

 

[rossw]

If we can fetch that sun rise and sun set data from public web servers, that is probably easier for you.

Easier and more flexible. Program in a URL or two, be very nice if the device could send something useful as an ID - its MAC address or hostname, that way the reply could be tailored to suit the job.

But we are working hard on fetch VAR back due to Microchip TCP stack would not reassemble data -- which is undersandable, since some TCP reply could be 2000 bytes, with total RAM 3808, there is no way TCP stack can do anything by default. We have to manually patch up the reply from servers, and useful reply might be break into two packets, in addition, different server and different CGI can have totally different reply.
Another problem would be, if fetch from external server failed for any reason, that could ruin all your logic.

So, the answer is:
1. Stipulate that the response WILL be in x format. Something suitable and easy to parse. Like, a "plain text" response that must be no greater than (x) bytes.
2. You could set or clear the zero bit or other testable flag (you already have bnz/bz so that's sensible to use) if you were unable to parse a reply. That would cover for (a) no response from server, (B) unusable reply, (c) wrong URL etc.

CRC16 lookup table has 256 two bytes number like 0x1234 or 0xFEDC. To store another LUT in ROM like that is not hard. If you only need one degree resolution, 90 degree will only has 90 values. We will need more information then work on that for you.

ROM based LUT for sin/cos would be handy, but as I said - a LUT in user (program) memory space would be FAR more versatile.

 

[CAI_Support]

User defined means store them in the EEPROM, then it must read in to the RAM. We do have RAM and ROM space, but not RAM on this board to support that.