@virtualmkr said in CAN bus transport implementation:
I'm not a "radio guy", but I think this code change looks fine. When sanity check fails then MySensors core calls transportInit() which would try to re-initialise the MCP2515 module.
Ok. I'll update code.
@virtualmkr said in CAN bus transport implementation:
I have done some modifications in the CAN transport files.
@Adam-Slowik I would like to create a PR in your forked repo. Then we can discuss the code changes in GitHub. Would that be Ok for you - do you have time for this?
Sure. Make PR. I'll try to review it within 48h.
@virtualmkr said in CAN bus transport implementation:
When I send 32 byte message I observed the sub telegrams do not always arrive in send order
Other limitation I see is the limited CAN telegram buffer of 3 packets in the MCP2515 module. I'm afraid for reliable operation with MySensors a change from polling to interrupt mode is required.
I think this two issues are linked. Now packets are sent in correct order (could You verify it?). If packets are sent in short periods We should use interrupt to keep MCP2515 buffers empty. When We fail to keep buffers empty (due to polling mechanism) We receive sub telegrams in mixed order. This theory could be true if MCP2515 buffers are implemented as LIFO. I'll look into documentation to figure it out.
Anyway both fixes are worth to implement. I'll try to do this over weekend.
@Trand Well, sorry, but nothing else comes to mind. If you have a scope or logic analyzer then you need to watch the actual signals on the wires and see what is happening.
If you don't, then you should pick up a cheap logic analyzer. You can get one for $10 and it's invaluable for tracking down things like this. I don't know where you are based, but I see them on Aliexpress all the time.
@gerritv
I am using v1.3.0 of the BH1750 library which I think is the most recent version on github (updated Jan 22).
I had the same issue when using ONE_TIME_HIGH_RES_MODE in that the sensor would return an accurate light level on first power up but then each subsequent read would return the same value regardless of the light level.
Reading through the source code (I think) the measureReady statement is still missing a configure statement to re-power up the module.
So I put a configure statement in the main loop of the sketch which (I think) powers up the module and then a wait for 200ms to allow enough time before reading.
void loop(){
if (!lightSensor.configure(BH1750::ONE_TIME_HIGH_RES_MODE)){
Serial.println("Could not power up light sensor");
}
wait (200);
if (lightSensor.measurementReady()) {
uint16_t lux = lightSensor.readLightLevel();// Get Lux value
#ifdef MY_DEBUG
Serial.println(lux);
#endif
send(msgLight.set(lux, 1));
}
etc...
My device is a combination temp/hum sensor using a HTU21 and light sensor using BH1750.
I now get accurate light levels each read cycle.
In BH1750 continuous mode the current draw was about 0.15mA between reads. In one time mode it is now reading 0.01mA on my ammeter, i.e. almost too small to read.
Reporting back: Yeah, I just now contacted them. The price they're quoting now is $3.89 per module and they want $35 shipping. They said "Mass production is about 2.5-2.2 USD", which is higher than what their Alibaba listing says for quantity 3 sample pricing, which they now say is 2 years out date and should be ignored. Checking, I see that the quoted pricing is actually slightly worse than the $3.82/unit in their Aliexpress store. What a joke. I mean, given that this is allegedly the manufacturer talking, who can't be bothered to keep their own Alibaba listing updated even though it's allegedly two years out of date.... I guess the pricing indicated on Alibaba means nothing, which certainly explains a lot.
