rogermiranda1000:
My idea it's to leave the chip on the main I2C bus and also add the I2C mux. The I2C mux will have the shield I2C bus. Thus, no on-board surgery.
I don't see how that will solve your problem. The devices with the same addresses need to be on the switched side of the mux. Without surgery to the UNO WiFi, the crypto unit is going to be on the processor side of the mux and will still respond regardless of the mux setting. The mux doesn't change the address of the target device. It just allows you to have multiple target devices with the same address, but they have to all be on the switched side.
I just thought I'd chip in, as I have the same situation: Uno WiFi rev 2 and the Spark Fun Weather Shield.
I had been tinkering with the shield on a regular Uno and, like several people, I’d assumed I’d be able to lift and shift to the Uno WiFi. I quickly ran into the I2C address clash, however, I was already a little unhappy with the barometer in the shield. I think it’s a 115A2?
I found that the pressure reading was very erratic, and the temperature readings from both the pressure and humidity sensors were quite inaccurate. I managed to solve all my problems by using a DPS310 for pressure. It seems to be far more accurate for both pressure and temperature. As an added bonus, it has two different I2C addresses, and an option to use SPI.
For humidity, I’m currently using a trusty old DHT-22.
With regards to IRQs, I found IRQ3 works fine for the wind sensor, but I think there may be some issue using IRQ2 for the rain sensor. I seem to be getting spurious readings during daylight hours, so I suspect some arguments going on with the light sensor. I’m currently tinkering with that, so any advice would be gratefully received
So you did not add a DPS310 to the shield, you stopped using the shield completely and added other sensors to the board.
I think that is the best way.
Koepel:
Maybe the best conclusion is that your board does not work with that shield. period.
We really need a better name. The "Arduino Bitter Wifi board" might have too much frustration in its name. What about "Arduino not-Uno Wifi board" ?
See the reference attachInterrupt(): attachInterrupt() - Arduino Reference.
The preferred way is to use digitalPinToInterrupt().
Sparkfun does not do that in their library.
See the sparkfun library and search for "attachInterrupt", add that "digitalPinToInterrupt()" and choose the pin numbers that can be interrupts. The Arduino not-Uno Wifi board can use any digital pin as interrupt.
I'm tring my best but I'm not getting anything.
I'm using SoftWire on A4/A5 pin.
Even running SoftWire's scanner over that pins are not detecting anything...
rogermiranda1000, I think that is not a solution. Beside that, it will not work because of what markd833 wrote. Now you have both software and hardware that will not lead to a solution.
If you want the full Arduino experience with your board and the Arduino cloud, then keep that board as it is. Add a few sensors and forget about the weather shield.
Koepel:
The preferred way is to use digitalPinToInterrupt().
Sparkfun does not do that in their library.
See the sparkfun library and search for "attachInterrupt", add that "digitalPinToInterrupt()" and choose the pin numbers that can be interrupts. The Arduino not-Uno Wifi board can use any digital pin as interrupt.
Thanks for this - I've tried it and am still getting spurious events, however, It's probably because the shield is still in place and something is interfering. I think I'm going to need to remove the shield and build my own connectors for the wind and rain sensors.
Another thought for you - if you are using a software I2C implementation on pins A4 & A5, then don't forget that plugging in the weather shield will route your software I2C SCL & SDA signals across the weather shield and onto the hardware I2C SCL & SDA signals coming from your UNO WiFi Rev2. Effectively creating a short between software I2C and hardware I2C.
If you can isolate the hardware SCL & SDA signals on the weather shield - maybe by cutting the 2 tracks by the connector (slightly less drastic than chopping off the pins on the header), then you should be able to use A4 & A5 to talk to the sensors.
That should give you a software based I2C solution on the UNO WiFI Rev2 whilst allowing you to plug the shield into a plain old UNO and use a hardware I2C solution, or even the same software solution on both.
markd833:
If you can isolate the hardware SCL & SDA signals on the weather shield - maybe by cutting the 2 tracks by the connector (slightly less drastic than chopping off the pins on the header), then you should be able to use A4 & A5 to talk to the sensors.
That should give you a software based I2C solution on the UNO WiFI Rev2 whilst allowing you to plug the shield into a plain old UNO and use a hardware I2C solution, or even the same software solution on both.
That's exactly my idea.
Obviously, I didn't connected SDA nor SCL, but the code didn't work.
Another thought just to attempt to get anything working on your UNO WiFi. The SoftWire library has an example sketch called ListDevices. If you run that on your UNO, does it report any devices?
Hmmm, that UNO WiFi really doesn't want to play does it.
Ok, so we know that connecting the weather station shield up to a plain old UNO works using hardware I2C. Given that, I think it is safe to say that the weather station shield is working.
I may have missed it but did you use stacking headers (or even ordinary pins) on your weather station shield to connect it to the UNO and UNO WiFi? I wonder if there are other pins on the shield that are causing problems.
Looking at the [schematic](http://cdn.sparkfun.com/datasheets/Dev/Arduino/Shields/Weather Shield.pdf) for the weather shield, it looks like you can get the basics going with just GND, 5V, VIN (needed to generate the on-board 3.3V), SCL (on A5) & SDA (on A4).
Do you get any joy with the I2C scanner with just those signals connected?
markd833:
you can get the basics going with just GND, 5V, VIN (needed to generate the on-board 3.3V), SCL (on A5) & SDA (on A4).
On Arduino UNO Wifi the program doesn't detect anything (even using a digital pin, just in case).
I've tried the same program on a regular Arduino UNO and guess what... 0x40 and 0x60 found. I think Arduino team tried their best to prevent this shield from working...
Edit: using SoftWire on UNO Wifi over SDA/SCL (I wanted to check if the board is compatible with the library) it did detect the crypto chip on 0x40...
After powering the Arduino over a 9V battery my program was able to capture the temperature and humidity.
Now I'll try it with the pressure sensor and then the wind/rain sensors.
The schematic that I saw for the UNO Wi-Fi showed that Vin came from the barrel jack. If you were powering it via the USB connector, then that would explain the lack of voltage on Vin.
I'm not the best person to ask regarding code reviews! If it does what you want and it generates the correct results then I'd say it's good to go. There will always be differing opinions on whether the code should be implemented this way or that way.
EDIT: Just reading back over the last few posts regarding Vin. If it's still connected to +5v, then it won't be reading Vbatt / Vraw.
rogermiranda1000:
I found the cause:
For some reason Vin on Arduino UNO Wifi doesn't output voltage. I connected shield's Vin into Arduino's 5V and now it's working.
After reading this I added a jumper cable. So far I've had no anomalous readings from the rain sensor code. Prior to this, I haven't gone 24 hours without these readings, so I'm reasonably confident that it's fixed my issues - here's hoping!
