Hey!
I am trying to connect a sensor by I2C, I am connecting the SDA to D0, SCL to D1, everything by the book.
but for some reason, when I start the code, in the middle of the flash my spark core is going offline and online, and keeps blinking green, and than go back to cyan, and repeat offline online and blinking green.
when I try to flash new code, it fails and keeps the green blinking, so far in order to be able to flash new code I do a factory reset.
there is a lot of code so I dont think there is a point to add it.
it looks like if I dont connect the sensor, the code is fine, but it doesnt find the sensor (doh!)
but once I connect it via the I2c it goes into crazy green blinking mode
Anyone have any idea what I can do in order to find the problem?
Some follow up:
it looks like that if my vin gnd and SDA are connected it is looking for the sensor but it doesnt crash, but once I connect the SCL to D1 it goes crazy, blinking green and keeps going offline
Here is the code from Adafruit_BNO055.cpp that connects to the sensor:
/* Enable I2C */
Wire.begin();
// BNO055 clock stretches for 500us or more!
#ifdef ESP8266
Wire.setClockStretchLimit(1000); // Allow for 1000us of clock stretching
#endif
/* Make sure we have the right device */
uint8_t id = read8(BNO055_CHIP_ID_ADDR);
if(id != BNO055_ID)
{
delay(1000); // hold on for boot
id = read8(BNO055_CHIP_ID_ADDR);
if(id != BNO055_ID) {
return false; // still not? ok bail
}
}
anyone have any idea what might be the problem?
Thanks
Does your sensor have pull-up resistors on SDA and SCL? Many breakout boards like the ones from Adafruit and SparkFun have them, but bare chips generally don’t. They’re required on the Photon and Electron. A 4.7K or 10K resistor on each of SDA and SCL to 3V3 for 3.3V sensors. If you’re powering a Photon by USB and using 5V sensors powered by VIN, then use pull-ups to VIN instead.
I dont think it does, where can I check if it has a pull-up resistors?
and I use spark core, not photon nor electron, so maybe it is not the problem.
and yes I am powering my core with the USB right now, and I tried both 3.3V and 5V
You’d have to look at the schematics for the sensor board to be sure.
Here are the schematics, do I need to add pull up resistors, and do I need to add anything?:
You shouldn't need pull-up resistors; they're included on the board.
SCL - I2C clock pin, connect to your microcontrollers I2C clock line. This pin can be used with 3V or 5V logic, and there's a 10K pullup on this pin.
SDA - I2C data pin, connect to your microcontrollers I2C data line. This pin can be used with 3V or 5V logic, and there's a 10K pullup on this pin.
so if the pull-up are not the problem, why does my core start blinking green when I connect the sensor?
I think we have already been there in the other thread - please don’t open multiple threads for the same issue
So I’ll move the other posts over here
A bus is meant to interconnect multiple devices, so you can have two (or more) sensors on the same I2C bus (up to 127 devices).
The tricky thing is how to explicitly talk to only one of them, and for that reason I2C devices usually have an assigned address.
Some sensors/sensor boards have some means to set the address in order to have multiple of the same kind connected and still being able to distinguish them.
For that reason it would be good, if you could be more elaborate about the sensors you are going to use.
But even if your sensors share one fixed address, you could use another pin to mutually power/enable one of them at a time.
Having said this, my proposal from above to use Serial2 instead of RX/TX Serial1 is not an option, since you need D0/D1 for I2C.
But you might not need serial after all when reading the sensors with the Core direct, if you can clarify how exactly you mean this
How exact does same time have to be? Will a few milliseconds make a difference?
All the time is not possible anyway, since communication alone and linear program flow will inevitably incur reading gaps.
The sensor I am using is: Adafruit BNO055 IMU
lets say at time t the info sensor 1 gives me is x1(t1) and sensor 2 gives me x2(t1)
I want to be able that for any given time t1 I will be able to do x1(t1) - x2(t1) on my spark core,
I am willing to give error between each x1(t1) and x2(1) of 1 millisecond, but a few milliseconds is too much.
Will a bus be able to stand this demands?
if yes, do you have a good guide for a beginner about bus and how to implant one?
if no, do you have any other idea how I can achieve it?
Thanks!
OK, looking at that sensor it features an ADR pin which allows to select an alternative address and hence you’ll be able to read both sensors with one bus in a few microseconds.
The wiring is easy, just parallel wire each sensor
Vin1 || Vin2 -> Vin or 3V3
GND1 || GND2 -> GND
SDA1 || SDA2 -> D0
SCL1 || SCL2 -> D1
ADR1 open
ADR2 -> 3V3 or 3Vo on the shield
Usually you would also remove one set of pull-up resistors, but here they use 10k so two in parallel will be OK.
@Zodon, getting millisecond sampling jitter between the two BNO055 may be possible on the Core but somewhat tricky due to everything else the Core is doing. How do you plan to send data to the “cloud” and how often?
Can you explain a bit more about the sampling from both sensors? its important to get them both in a rate of 100hz, or the project wont work, why is it tricky on the core and what else can I use?
I want to send all the data to the cloud, I saw that the particle cloud can only get data every 5 seconds or so, so I guess I will use some other cloud (maybe AWS?) to send all the data I collect, meaning every 1 millisecond.
is this project even feasible?
Thanks
@Zodon, doing 100Hz sampling is fine on either the Core or the Photon. However, sending data to the Particle Cloud will be limited to once per second if you use the publish/subscribe mechanism built into the firmware. As such, you will need to look at direct TCP or UDP communications and possibly HTTP though the overhead may be an issue.
Realistically, I don’t believe you will be able to send data reliably to a Cloud server at 1ms intervals, primarily due to the nature of the internet. You also have not indicated how much data you will be sending at this interval (number of bytes). Your solution most likely requires either a local server, on the same network where latency is not an issue, or a look at how data can be buffered, compressed and sent at slower intervals. If you search the forum, other members have asked similar questions so it may be worth exploring these. 
You can only expect a new reading from your sensors every 10ms, so why would you need to send data every 1ms?
BTW: 1ms is about the time one iteration of loop() plus background tasks takes.
ok you guys are right and totally made me think about the way I want to send the data.
instead of sending each sample of a sensor(1 line of data),
I can store X line together and send them every Y time, of course I need to see how much is X so I can hold all of it on the core without overflowing my memory.
I will look around for best cloud service that can store this, or maybe even now I can send once every 5 seconds and use the publish function
By the way, what about sending the data to a smartphone and from the smartphone to the database? will it be better?
Thanks a lot for both of you @ScruffR, @peekay123!
Publishes have a data limit, so keep those in mind as well. Also, the Particle cloud currently does not offer storage yet, so you'll have to find another solution for that regardless.
I don't think it would be. Adding a middleman to stuff is rarely good for optimization. Especially considering that you'd go over the cloud, through the internet, to your Phone, and then back to the internet. You might as well skip that and go straight to where you want to be.
The problem is not the same,in my other thread I tried connecting the core to an arduino mini via TX/RX but I know what I did wrong there.
Here I do everything fine, and yet my core start blinking green for no reason and doesn’t connect to the sensor…
Granted, the thread started off that way but then turned towards the use of that sensor and hence I moved the posts that were not fitting to the original topic anymore over here.
BTW, the green blinking you see is most likely caused by some code that blocks the cloud house keeping for more than 10sec.
To test that theory add SYSTEM_THREAD(ENABLED) to the top of your project.
This way your device should at least stay connected but it won’t get rid of the blocking code section.