[Palmyweather]

Hi guys

I have just built the WeatherDuino Pro2+ project which is working very well. To maximise the functionality of this new receiver, I needed to perform a software update to the transmitter. I have gone from build version 2.0-b008 to build version 2.0-b015 and have spotted something. Since the update of this TX software, I am now getting solar radiation readings through the night which I was not previously. These readings are between 12 - 16W/m2.

Both of my receivers, the new WeatherDuino Pro2+ (software build 1.0 b018) and original WeatherDuino pro2 (software build 2.0 b011) are giving the same readings, so I can only assume it is a variation in the transmitter software. Is the solar radiation being processed differently in the latest TX software? What might be the best way to correct this?

At the same time of updating the software for the TX unit, I also update the physical  TX board from board version 3.11 to version 3.12, so maybe there is a difference there too?

I have not updated my original transmitter's software and tested it at this stage as I have only just noticed the issue tonight. And of cause because the readings are above the "Theoretical Maximum", it looks like we might have 24 hours of "daylight" here today (wishful thinking after the lousy summer we have had).

I have attached some before and after results of the graphs I am now producing through the night.

[attachment=943]  [attachment=944]

 
Kind regards,
Palmy Weather

[werk_ag]

Both of my receivers, the new WeatherDuino Pro2+ (software build 1.0 b018) and original WeatherDuino pro2 (software build 2.0 b011) are giving the same readings, so I can only assume it is a variation in the transmitter software. Is the solar radiation being processed differently in the latest TX software? What might be the best way to correct this?

At the same time of updating the software for the TX unit, I also update the physical  TX board from board version 3.11 to version 3.12, so maybe there is a difference there too?

Hi,

The routines which read the Solar Radiation and UV sensors don't change since almost a year. In fact those routines only read the Arduino ADC0 and ADC1 channels, do a 2.5 min rolling average and send the raw value to the receiver.
Regarding to this matter also there aren't any differences between the TX v3.11 and TX v3.12, so the reported behaviour should be related to something with the installation of the new TX board.

Things you could try:
- Try to check the cable connections that come from the Solar Rad / UV sensor to the board. Put them away from interference sources.
- Check if C7 is a 10uF/16V Tantalum Capacitor and not just an electrolytic cap.
- Change the Arduino Nano by the one used on the TX v3.11 board

I have not updated my original transmitter's software and tested it at this stage as I have only just noticed the issue tonight.

This is confounding me... are the reported results from the same Solar / UV sensor or from a new one?

[Palmyweather]

Hi Werk

Thank you for your reply. Just to clarify, I have not chanced any weather sensors, only the transmitter circuit board and the software it runs.

I have done some checks on the system during the day today. By covering the solar sensor to simulate night, I measured exactly 0W/m2 in total darkness. Both times I did this (once in the morning and once in the afternoon) they gave the same, expected result of 0W/m2.

I can confirm I have a 10uF/16V Tantalum capacitor in C7 in the Transmitter board 3.12. This made me question what I had in my original Transmitter board, 3.11 and guess what I spotted that I had used: Electrolytic capacitors in C7 and C8. Maybe by using the correct type or capacitor, it has simply made the system more sensitive if these capacitors have an effect on this part of the circuit?

So, I have done nothing for today. I have left it alone without modification to see what happens tonight. But tonight I will try turning off the outside spotlight used so the webcam can see the weather station by night. I do doubt that this is what it is picking up however.

Thank you for your help once again. I will let you know how I get on; if the same problems occur tonight, I will try replacing the Arduno Nano micro controller.

PalmyWeather

[werk_ag]

I gave a look to your the real time graphs, and it seems those abnormal "night readings" during last night, suddenly stopped at 3:32, and up to near the sunrise they haven't appeared again.

I can confirm I have a 10uF/16V Tantalum capacitor in C7 in the Transmitter board 3.12. This made me question what I had in my original Transmitter board, 3.11 and guess what I spotted that I had used: Electrolytic capacitors in C7 and C8. Maybe by using the correct type or capacitor, it has simply made the system more sensitive if these capacitors have an effect on this part of the circuit?

The circuit design used in the AMS1117 series requires the use of an output capacitor as part of the device frequency compensation. The addition of a 10 to 22 uF solid tantalum capacitor on the output will ensure stability for all operating conditions.
...
To further improve stability and transient response of these devices larger values of output capacitor can be used.

C7 is supposed to do this job on the 5V voltage regulator. Following the datasheet it should be tantalum, however I also already have used electrolytic caps in the output of AMS1117 regulators.

[Palmyweather]

Well great news, I think the problem is solved. It was in fact the Arduino Nano chip itself which was causing this problem it would seem.

Last night I plugged the original Arduino Nano from the original 3.11 TX board, still with the older TX software running on it, into the new transmitter board 3.12. It went all night without a hitch. Today I have reprogrammed the original Arduino Nano with the new software and so far tonight (2 hours in) there are no high spike readings.

I wonder what could have caused the the Arduino Nano I initially used in the TX 3.12 board (one I was keeping as a spare part) to become unhappy and give this sort of issue? I would have hoped that one Arduno would perform similar to the next, especially when you buy them from the same supplier. Must make a note to not use my spare Nano in future for any weather projects.

Thank you for your help and suggestions,
PalmyWeather

[werk_ag]

I would have hoped that one Arduno would perform similar to the next, especially when you buy them from the same supplier. Must make a note to not use my spare Nano in future for any weather projects.

As seen, that is not always truth. Probably for you to use the new one, the solar / UV sensor should be recalibrated again, perhaps just in the software. Even in the dark, the Solar / UV sensor always output some voltage, with some Arduinos the default value hard coded in the software to compensate for this is not enough. Take a look on the RX software, RX_TX section and you will find a line of code where this compensation is done. Basically it discards readings below a given threshold.
Users can then modify the next line of code and set the selected threshold as a new zero point.

[zitoune]

I start having some values at night with the UV sensor (not the solar sensor)/ It's been like this for a few weeks, started with just a pic or two, and have now continuous pics during the whole night. I think this has something to do with the humidity in the box - I will dismantle it and dry it to check.

Zitoune

[zitoune]

I start having some values at night with the UV sensor (not the solar sensor)/ It's been like this for a few weeks, started with just a pic or two, and have now continuous pics during the whole night. I think this has something to do with the humidity in the box - I will dismantle it and dry it to check.

Zitoune

Yesterday I opened my enclosure and noticed - as expected - that some wter leaked inside through the hole made for the unique wire input. The wire moved a bit and the silicon did not hold it tight.
I cleaned the enclosure as well as the PV cell (there was a good level of dust on it), but the glass covering the UV sensor was crystal clear.
I used some Araldite to secure the wire and seal the hole.

When everything was put back in place I noticed for the first time a value of 10W/m2 at night. I then update the threshold from 4 to 15 in the RX_TX tab and all readings are good now.

Zitoune

[f4aii]

I had for a few days a night value that oscillated between 5 and 6w whereas previously it was not there.
You have to modify line 236 on RX_v410_B008:

Code:

// RX_Data[2] ---- Solar Data
     uint16_t SolarRad;
   
     #if (Solar_Sensor == 1)      // --- WeatherDuino Solar Cell Pyranometer (Solar / UV interface R2= 2700 Ohm)  
       if (RX_Data[2] < 4) RX_Data[2] = 0;
       SolarRad = map(RX_Data[2], 0, 1023, 0, 1400);    // Outputs an integer, between 0 and 1400 W/m2
     #endif
     #if (Solar_Sensor == 2)      // Apogee SP-110: Self-Powered Pyranometer (Solar / UV interface R2= 4900 Ohm)
       if (RX_Data[2] < 4) RX_Data[2] = 0;        
       SolarRad = map(RX_Data[2], 0, 1023, 0, 1450);              // Using OP - Formula outputs an integer, between 0 and 1450 W/m2
       //SolarRad = round(((RX_data[2] * (1100 / 1024.0)) * 5);   // Not using OP. Sensor connected directly to ADC input
     #endif
     #if (Solar_Sensor == 4)      // Apogee SQ-110: Sun Calibration Quantum Sensor (unit is µmol m-2 s-1)
       SolarRad = round(((RX_data[2] * (1100 / 1024.0)) * 5);
     #endif

if (RX_Data[2] < 4) RX_Data[2] = 0;
i modified this to: if (RX_Data[2] < 7) RX_Data[2] = 0;

[f4aii]

version: RX_v500_b002
in the tab RX_TX line 234

Code:

#if (Solar_Sensor == 1)      // --- WeatherDuino Solar Cell Pyranometer (Solar / UV interface R2= 2700 Ohm)  
        if (RX_Data[2] < 7) RX_Data[2] = 0;
        SolarRad = map(RX_Data[2], 0, 1023, 0, 1400);    // Outputs an integer, between 0 and 1400 W/m2
      #endif