I’d think the timing might be rather wonky with that approach and also the protocol settings (start, prio, stop) may not match.
Just makes me appreciate the FTDI chip so much more now. I just sent the bits to it using two lines of arudino code and it was able to package them up nicely for the PC to read it. Didn’t realise it was going to be so much work with the Photon, especially since I assumed the Photon already had everything in one small package.
I’m wondering if I should just give up on being able to read the eBUS using the Photon and just use a Nano arudino with an FTDI.
What I don’t understand is that the simple opto circuit is able to output a RS232 5V TTL signal. But I can’t seem to get that to work within the Photon even though I can sense the High and Low voltage changes. What I thought I would do is get the HIGH and LOW state written to a Digital Output and then connect that to the RX on the Photon and then send that to the USB Serial. All have been opened using the same baud and SERIAL_8N1 but yet it won’t work.
I think I understand the approach you are taking: take the 24V differential eBus signal at 2400 baud and try to read the value using a voltage divider and analogRead() and then output the digital value after comparing to a threadhold using digitalWrite() where the output digital pin is connected to RX, the Serial1 input. That is quite a trip!
I don’t think this is a good approach due to variable latency in all the software and loop overhead. It should work fine if you use one of the optoisolator or op-amp circuits and just drive the RX pin directly.
Think of it this way: Each bit at 2400 baud is 416uS wide and you want to sample the bits at a rate at least double that for safety (208us between samples), but loop can’t “go around” in that time, so you miss bits. One a very simple micro, there is no “housekeeping” to be done for the network while going around the loop() function, so it can go very fast, but on a Photon, the network and cloud connection service happens during that time. You might be able to make an interrupt driven approach work, similar to soft-serial, but using loop() is a no-go, and why would you?
Just use the hardware resources on Photon, like the built-in hardware USART and you will not have these problems.
1 Like
@bko you’ve just confirmed my suspicion that the Photon couldn’t keep up within the loop. I had asked that question right at the start. But I thought the ARM cpu was so much faster than the AVR that it could cope with all the overheads etc.
I’ll give the opto route a try and see how I get on. Thanks a lot guys for all the help so far.
The Photon can keep up with it in loop() when you use it the same way as the AVR: Withouth the WiFi connection.
If you add SYSTEM_MODE(MANUAL) you'll cut out the WiFi/cloud housekeeping @bko has mentioned and you'll see much better performance.
But to reiterate: Doing it in loop() is not the best choice - not even on an AVR - even when it works.
Doing it via interrupts will even allow you to keep the cloud functionality available.
And about the opto route, you'll still have to consider the electric specs of your protocol to clearly distinguish between HIGH and LOW as discussed in the earlier part of this thread.
BTW:
Where?
Currently I have my boiler in the loft and I was trying to kill two birds with one stone. Get my boiler data, measure the temperature in the loft and send all this data to the cloud. Currently I have the Arduino/FTDI doing the boiler data and then handing that data off to a PC and then that send the data to the cloud.
I’ll give the mikrocontroller circuit a go and see how I get on with the Serial1.RX directly.