As I replied above the while loop is only for checking if sensor is sending data to mcu or not cause if it not sending data then i mean the "0 /zero" will be send all the time when sensor is off or not connected, but yes i agree that the reason for not sending data is we did not use delay in last of the code, cause which may be our data is not send over console, while it will reading data from sensor, last time when i run i2c scanner code it publish successfully cause in that code also we use delay(5000), mean 5 sec so i try as delay in my code and then try it.
the led is not useful it just toggled later i will use it with sensor data after read it successfuly
I don't think this is entirely correct, but I am not a programmer so stand to be corrected This is the reason I wanted to add a simple Particle.publish() before and after the while loop(). This will show where (in indeed the case) the code stops running. If the publish in the loop occurs,
Particle.publish("Entering Loop", PRIVATE);
we know to look elsewhere. If this publish does not take place, then the code is indeed block by the while loop.
Alternatively, like @ScruffR suggested, remove the while loop then. Also like I mentioned before and Scruff mentioned here, add a 1s delay in the loop so not to exceed the publish limit (4 in 4s).
Thank you all, yes I will correct the delay in my code and also use you method of particle.publish before and after entering void loop() and exit setup loop() to know where we facing the problem after add delay of 1sec delay in the code.
My understanding is that if it is not successfully reading from the sensor (not only the I2C address), this while loop will block you code... but again, I stand to be corrected which I why I suggested the two publishes, one before and one after... This is the way I test whenever I have problems reading from sensors and 9/10 times it is the while loop block the rest of the code as it is waiting for successful initialising or comms and get's stuck there as there is no exit condition... AGAIN, I stand to be corrected
I'd say that is not true (to say it mildly ).
When your sensor is connected via I2C, how would you be able to check whether the sensor is sending data by looking at USB Serial.available()?
It would be useful to deduce whether the code actually reaches loop() or not.
if the LED blinks, the issue should be searched in loop()
if not, the issue is probably before that
Another way to learn more about the behaviour of your code would be tied to this question
I'm always astonished why people try to defend an obviously not working position instead of just answering the questions asked and try the suggestions given
thank you everybody
success! we have serial data for xyz in the monitor
we did have to comment out the serial available
here is the code that ended up working
we do have a strange issue in the the boron seems to reset every 32 seconds
the green light on boron starts to flash and data on serial monitor stops and it prints out:
then goes back to xyz data
\any ideas why boron would do that?
// This #include statement was automatically added by the Particle IDE.
#include <MPU6050.h>
// Once you import this library into an app on the web based IDE, modify the code to look something like the following.
// This code is a heavily modified version of the MPU6050_raw.ino example found elsewhere in this repo.
// This code has been tested against the MPU-9150 breakout board from Sparkfun.
// This #include statement was automatically added by the Particle IDE.
#include "MPU6050.h"
int ledPin = D7;
// MPU variables:
MPU6050 accelgyro;
int16_t ax, ay, az;
int16_t gx, gy, gz;
bool ledState = false;
void toggleLed() {
ledState = !ledState;
digitalWrite(ledPin, ledState);
}
void setup() {
pinMode(ledPin, OUTPUT);
Wire.begin();
Serial.begin(9600);
// The following line will wait until you connect to the Spark.io using serial and hit enter. This gives
// you enough time to start capturing the data when you are ready instead of just spewing data to the UART.
//
// So, open a serial connection using something like:
// screen /dev/tty.usbmodem1411 9600
//while(!Serial.available()) SPARK_WLAN_Loop();
Serial.println("Initializing I2C devices...");
accelgyro.initialize();
// Cerify the connection:
Serial.println("Testing device connections...");
Serial.println(accelgyro.testConnection() ? "MPU6050 connection successful" : "MPU6050 connection failed");
}
void loop() {
// read raw accel/gyro measurements from device
accelgyro.getMotion6(&ax, &ay, &az, &gx, &gy, &gz);
Serial.print("a/g:\t");
Particle.publish("a/g:\t", PRIVATE);
Serial.print(ax); Serial.print("\t");
Particle.publish("AX" + String(ax) + " \t", PRIVATE);
Serial.print(ay); Serial.print("\t");
Particle.publish("AY" + String(ay) + " \t", PRIVATE);
Serial.print(az); Serial.print("\t");
Particle.publish("AZ" + String(az) + " \t", PRIVATE);
Serial.print(gx); Serial.print("\t");
Serial.print(gy); Serial.print("\t");
Serial.println(gz);
toggleLed();
delay(1000);
}
Keep in mind the more simplified way of publishing I suggested (and implemented here) was merely to get you going. Now that you know the device is working, I suggest you follow the advice given by Scruff on how to construct a message that would contain all the info and use only a single publish.
I recall also mentioning a way you could do it, but it is safe to say, Scruff knows best
For future use... keep in mind each time you use Particle.publish(); it is well.... a publish. The rate limit counts towards this and not the number of times you function - in this case void loop() - runs.
ps: I once had an issue with Boron's connecting/disconnecting due to very poor signal (<25%). Also took quite some time to connect to towers.
thanks again for everybodys help, we are still working on Scruff’s publish recommendation..
im not sure if my boron is a part of particle product but ill paste a screen shot below of what i found in the console about the devise.
ive never put a particle in listening mode
and am totally clueless on how to do that😅 (chat gpt said hold mode button for 3 sec )
but i want to wait for your approval before i try that
also clueless on how to run particle serial identify and particle serial inspect😅
sorry im new to particle
hhmmm... looking at the screen grab you share, my guess would be that your frequent disconnects might be due to the weak signal strength (28%) and what seems to be non-existing signal quality (0%). Maybe somebody can correct my if I am wrong, but we have had similar challenges in remote locations.
Do you have te antenna connected?
Regards, Friedl.
You should be able ti simply copy and paste the code @ScruffR sent This will output the constructed message to serial monitor as well as Particle cloud so you can view it in the console.
i do have antenna atached.
i copied and pasted scruffs code
and im getting all the data at one sec
no more reset but it eratic, some times it freezes for a sec or te
// This #include statement was automatically added by the Particle IDE.
#include <MPU6050.h>
// This #include statement was automatically added by the Particle IDE.
#include <MPU6050.h>
// Once you import this library into an app on the web based IDE, modify the code to look something like the following.
// This code is a heavily modified version of the MPU6050_raw.ino example found elsewhere in this repo.
// This code has been tested against the MPU-9150 breakout board from Sparkfun.
// This #include statement was automatically added by the Particle IDE.
#include "MPU6050.h"
int ledPin = D7;
// MPU variables:
MPU6050 accelgyro;
int16_t ax, ay, az;
int16_t gx, gy, gz;
bool ledState = false;
void toggleLed() {
ledState = !ledState;
digitalWrite(ledPin, ledState);
}
void setup() {
pinMode(ledPin, OUTPUT);
Wire.begin();
Serial.begin(9600);
// The following line will wait until you connect to the Spark.io using serial and hit enter. This gives
// you enough time to start capturing the data when you are ready instead of just spewing data to the UART.
//
// So, open a serial connection using something like:
// screen /dev/tty.usbmodem1411 9600
//while(!Serial.available()) SPARK_WLAN_Loop();
Serial.println("Initializing I2C devices...");
accelgyro.initialize();
// Cerify the connection:
Serial.println("Testing device connections...");
Serial.println(accelgyro.testConnection() ? "MPU6050 connection successful" : "MPU6050 connection failed");
}
void loop() {
char msg[128];
toggleLed();
accelgyro.getMotion6(&ax, &ay, &az, &gx, &gy, &gz); // read raw accel/gyro measurements from device
snprintf(msg, sizeof(msg)
, "ax: %4d, ay: %4d, az: %4d, "
"gx: %4d, gy: %4d, gz: %4d"
, ax, ay, az
, gx, gy, gz
);
Serial.printlnf("a/g: %s", msg);
Particle.publish("a/g", msg);
toggleLed();
delay(1000);
}
Not sure why you have three include statements for the same library.
Regularly sanitizing your code wouldn't be a bad habit
To run the particle serial ... commands you need to install CLI
How to put your device into its possible modes is an important thing to learn too
Consequently, Chat GPT gave you the correct answer and it's save to use.
However, getting yourself acquainted with Particle's own reference docs would be more useful than relying on the regurgitation of an AI.
It's always good to know someone/something that may know an answer, but knowing yourself becomes more fulfilling.
Also when you ask a specific question you typically only get the answer to that question (unless you stumble over a chatterbox like myself, who gives advice beyond what's asked for ). By investigating sources yourself you may stumble across answers you hadn't even thought of yet.
oh i sanitizes code down to one libray
but its still freezes up for a sec or two then it skips very fast and the led is flashin like a strobe at one sec intervals
did i mess up your code example?
Do you mean the led keeps flashing in irregular intervals or do you mean the messages arrive at console in bursts?
If the former is the case, then I'd guess it's due to bad reception - you can mitigate that to a certain extent by adding SYSTEM_THREAD(ENABLED) directly after your include line.
If it's the latter, then that is to be expected as the transfer from device to cloud to console to your local browser are asynchronous and may well fluctuate.
My implementation of loop() also toggles the LED, just as first instruction instead of last.
BTW, in case you are running Windows 10/11 you don't need to take a photo with your camera to make a screenshot - you can just use Windows+Shift+S to initiate the snipping tool to cut out a section of the screen and directly paste it in this forum's edit box.
This is the reason I wanted to add a simple Particle.publish() before and after the while loop(). This will show where (in indeed the case) the code stops running. If the publish in the loop occurs,
).
). By investigating sources yourself you may stumble across answers you hadn't even thought of yet.