So I have an Argon and a Xenon and haven’t had much joy with anything beyond the flashing LED.
I’ve played around a lot with the debug of various issues and am back to square one again - the LED flash works, so I’m happy that everything is ok and the problem is me, my coding and my router!
Some early observations/questions… please comment/reply/correct as appropriate…
I believe I have Gen3 devices.
Xenon has 1.2.0-beta.1 (pre-release) OS, I had 0.9.0 but saw the same issues outlined below. Moving up was an attempt to resolve some of the issues…
Argon has 0.9.0 OS
The CLI tells me both are online when one or both is powered off. Is this normal?
The Argon used to work fine on my home WiFi (for 2 weeks) but now it rarely connects, when it does it doesn’t last long. When connected, if I power cycle the Argon it fast flashes green but should still have the credentials… Trying to resend the credentials serially doesn’t succeed… It will find the SSID from Listening Mode and let me select it but wont ask for password… Leaving it for a long time (hours) it might connect.
Setting up a hotspot from my phone works - but only by unclaiming both and redoing the setup with the new hotspot credentials… it will still find the house WiFi but won’t connect… I’ve reset the router many times. Sometimes (rarely…) it will connect but more often than not it won’t. Not sure what the issue could be here as it used to connect no problem. Trying to add the house WiFi as a second/backup doesn’t succeed as in 2. above. Trying to circumvent the lack of progress to the password stage by serially flashing a credentials.json file doesn’t succeed either. Is there a way to read back all the stored WiFi networks?
I have some code i use to scan for I2C connected sensors - basically it searches through 128 addresses and returns the address of anything found. This returns random, irregular false positives. I have SDA and SCL pulled up with 10KOhms to 3.3V. It could be the code. Here it is:
void setup() {
//Set the speed of the I2C port on the Photon and start it.
Wire.setSpeed(400000);
Wire.begin();
}
void loop() {
bool devicesFound = false;
String newDevices;
//Step through all 127 possible I2C addresses to scan for devices on the I2C bus.
for(int i = 1; i < 128; i++){
//Make a general call to device at the current address to see if anything responds.
Wire.beginTransmission(i);
byte status = Wire.endTransmission();
if(status == 0){
//Device found so append it to our device list event string
char devices[20];
sprintf(devices, "Device at: %in", i);
newDevices.concat(devices);
devicesFound = true;
}
}
if(devicesFound){
//If there are devices connected to the I2C port then publish an event on what I2C bus addresses they were found at.
Particle.publish("New Devices", newDevices);
}else{
//If no devices were detecte then publish an event stating that.
Particle.publish("New Devices", "No Devices Found");
}
delay(2000);
}
Any/all I2C data I get back with sensors connected with pull-ups is 255. This is what led me to search for connected I2C devices in 4. above. I presume my issue here is with addressing the I2C device, but what am I doing wrong?
I’d really appreciate some feedback - I’ve spent 30+ hours in the last week trying to figure out my issues - some progress would be great. Learning loads, still enthusiastic but realize I need help!
Yes. This is due to the connectionless nature of UDP which Gen 3 devices use for cloud communication. It's a known issue and Particle is working on better indicators.
9 out of 10 times, the problem is user code. If you want us to take a look, you can post it here. However, Gen 3 device OS is definitely a work in progress so I'll give any code the benefit of the doubt.
Rarely does "unclaiming" a device actually help... it usually just complicates the matter if you are having connectivity problems. This behavior does sound strange. Have you held down the mode button 3 seconds to clear all credentials until the device is blinking dark blue (aka listening mode)? Or does safe mode help (blinking magenta)?
Try a lower resistance value to start. Try 4.7k Ohm. This may affect the 255 values you see as well. Alternatively, does your I2C slave also have pull-up resistors? If so, the value may be too low with multiple pull-ups in parallel.
The CLI tells me both are online when one or both is powered off. Is this normal?
Unfortunately, this is normal, it is a behaviour that Particle are aware of and are trying a couple of things to improve.
The Argon used to work fine on my home WiFi (for 2 weeks) but now it rarely connects, when it does it doesn’t last long. When connected, if I power cycle the Argon it fast flashes green but should still have the credentials… Trying to resend the credentials serially doesn’t succeed… It will find the SSID from Listening Mode and let me select it but wont ask for password… Leaving it for a long time (hours) it might connect.
Is the Argon running Tinker or your own Application (that you have posted)?
Is there a way to read back all the stored WiFi networks?
There is and a quick search in the reference docs will show you how. The passwords are not accessible from the wifi module for security reasons.
I have some code i use to scan for I2C connected sensors - basically it searches through 128 addresses and returns the address of anything found. This returns random, irregular false positives. I have SDA and SCL pulled up with 10KOhms to 3.3V. It could be the code.
First observation is that 10K pull up for 3.3V seems a bit high - have you tried a smaller value 2.2K?
IMO Wire.setSpeed(400000); in setup() is not required. Just use the default speed.
In Loop() you need to initialise the String object newDevices. It would be much better to define a char array since adding to an un reserved size string with consume a huge amount of space OR reserve a generous Sting object size.
Wire.beginTransmission(i) This should be a 7bit address so the for (int i ..) should be uint8_t i.
I haven't tried an I2C scanner in a while since it generally works first time every time!
RK: I have tried 4k7, also 2k2.. no joy. I have the pull-ups only on the Xenon SDA & SCL lines to the sensor (ADT7420FBZ) an Analog Devices Temperature Sensor Evaluation board.
Powered up this evening and connected first time to the house WiFi… lets call that a win and say last evening my WiFi was acting up.
So I made the changes suggested (to the I2C Scanner code posted above…) and I am using 2k2 pull-ups and there is a change in behaviour.
With no I2C sensor connected it runs fine and I can see “No Devices Found”…
Once I connect a sensor the serial port stops updating and everything stops. What could be at play here? I have two different senors, both do this, whether at D0/D1 or D2/D3.
I have tried 2k2, 4k7 and 10k pull-ups this evening to 3.3V and to 5V. Same results.
I cant flash new/different code to the Xenon without rebooting the Argon once the behaviour in 2,. above occurs. Why is this? Also, I can only ever flash to the Xenon when it is in Safe Mode (slow Magenta flash) Why is that? Should I be able to flash remotely (ie not having to be beside the Xenon to put it in Safe Mode every time via the buttons)?
Don't use 5V pull-ups! None of the GPIOs on Gen3 devices are 5V tolerant.
For D2/D3 I2C you'd need to use Wire1.
Probably because your code is not servicing the cloud tasks (e.g. Particle.process()) for the OTA update to work properly.
You should adopt a non-blocking coding style (avoid long delay(), long running loops, ...) and can try SYSTEM_THREAD(ENABLED) and/or regularly calling Particle.process()
Thanks @ScruffR
I’ll try add the SYSTEM_THREAD(ENABLED) and Particle.process() lines appropriately and see how I go.
I must try flash one of the examples in the Web IDE (Blink an LED) next time it wont flash for me (as above…)… this should work and therefore confirm my code is the culprit, right?
The Blink an LED sample isn’t the best since it uses delay() too.
I’d blink the LED rather this way
void loop() {
static uint32_t ms = 0;
if (millis() - ms < 1000) return; // bail out unless 1sec has passed;
ms = millis();
digitalWrite(led1, !digitalRead(led1)); // toggle LED 1
digitalWrite(led2, !digitalRead(led2)); // toggle LED 2
}
~Thanks @ScruffR that code you shared worked - as in I can flash it without having to got to Safe Mode…
My main problem now is i am unable to get any joy with I2C senors and I have 3 possible avenues to explore
Both my I2C sensors are duff. Its possible. I’ll try them on an SDP board and see if they are functional.
My code is just wrong. Entirely possible, although I’m running the code shared below as an I2C scanner and it just locks up.
I fried the Xenon SDA/SCL by using pull-ups to 5V in a misguided attempt to get something working.
Any thoughts welcome…
Thanks… RK
Code:
// --------------------------------------
// i2c_scanner
//
// http://playground.arduino.cc/Main/I2cScanner
//
// Version 1
// This program (or code that looks like it)
// can be found in many places.
// For example on the Arduino.cc forum.
// The original author is not know.
// Version 2, Juni 2012, Using Arduino 1.0.1
// Adapted to be as simple as possible by Arduino.cc user Krodal
// Version 3, Feb 26 2013
// V3 by louarnold
// Version 4, March 3, 2013, Using Arduino 1.0.3
// by Arduino.cc user Krodal.
// Changes by louarnold removed.
// Scanning addresses changed from 0...127 to 1...119,
// according to the i2c scanner by Nick Gammon
// http://www.gammon.com.au/forum/?id=10896
// Version 5, March 28, 2013
// As version 4, but address scans now to 127.
// A sensor seems to use address 120.
//
//
// This sketch tests the standard 7-bit addresses
// Devices with higher bit address might not be seen properly.
//
#include "Particle.h"
void setup()
{
Wire.begin();
Serial.begin(9600);
delay(10000);
Serial.println("\nI2C Scanner");
}
void loop()
{
byte error, address;
int nDevices;
Serial.println("Scanning...");
nDevices = 0;
for(address = 1; address < 127; address++ )
{
// The i2c_scanner uses the return value of
// the Write.endTransmisstion to see if
// a device did acknowledge to the address.
Wire.beginTransmission(address);
error = Wire.endTransmission();
if (error == 0)
{
Serial.print("I2C device found at address 0x");
if (address<16)
Serial.print("0");
Serial.print(address,HEX);
Serial.println(" !");
nDevices++;
}
else if (error==4)
{
Serial.print("Unknow error at address 0x");
if (address<16)
Serial.print("0");
Serial.println(address,HEX);
}
}
if (nDevices == 0)
Serial.println("No I2C devices found\n");
else
Serial.println("done\n");
delay(5000); // wait 5 seconds for next scan
}
void setup() {
pinMode(D7, OUTPUT); // for visual feedback
pinMode(SDA, INPUT); // place a jumper wire between SDA & SCL
pinMode(SCL, OUTPUT); // no other components
}
void loop() {
digitalWrite(SCL, !digitalRead(SCL)); // toggle SCL state
digitalWrite(D7, digitalRead(SDA)); // read and visualise the state
delay(500);
}
When the D7 LED blinks at ~1Hz your pins should be fine.
Firstly, your SDA/SCL LED toggle code worked and gave me confidence that I hadn’t fried my Xenon GPIO pins (D0 - D3).
Then I hooked up a Grove LCD screen I acquired today and it didn’t power up, nor did the I2C Scan pick up anything… because I had been powering it from 3.3V… Once I swapped that into VUSB it worked. The I2C scan worked too…
So back to my ADT7420… I2C found the address (not the default 0x48 but 0x49, 0x48 is the part’s address standalone, but on the Eval kit A0 is tied high incrementing to 0x49) and my Publish Temperature code works too when addressing 0x49! It works off both 3.3V and VUSB, as the datasheet says… I don’t have pull-ups in.
I dont know why this (I2C Scan) works now and didn’t before, tha twould be great to figure out… any thoughts?