Is it possible to have 315 and 433 at the same time?

whc2001 · April 30, 2019, 2:46am

I want to connect both 315MHz and 433Mhz transmit and receive modules to a ESP8266 with OpenMQTTGateway and have them working on both bands at the same time. But after checking the source code I found that seems like the RF module need to occupy two special pins rather than any. Is there a way so that I can do both? Thanks for answering!

whc2001 · May 1, 2019, 3:47pm

Well I discovered that I can change the pin assigning. However after I tried using a 315 module to connect to the two receiving pin one after another, I found that the data output is quite random (usually publishes on 433ToMQTT topic, sometimes on 315ToMQTT). I searched a little bit and discovered that this is due to a centralized interrupt callback and the MCU cannot decide which pin triggered it. Until now I would give up and use only one frequency.

1technophile · May 1, 2019, 8:10pm

Hello,

You are not the first to ask for this function, maybe whe should analyse this PR :

github.com/suda/RCSwitch

Rewrote library to allow for multiple RX pins

suda:master ← Ernest314:master

opened 08:24PM - 07 Jul 16 UTC

Ernest314

+701 -555

WARNING: This breaks the current API (although a fix is simple enough). Rewrote… example (`ReceiveDemo_Advanced.ino`) to use the new API. The number of RX pins must be defined at compile-time with `#define RCSWITCH_MAX_RX_PINS`. --- # Root cause Previously, if multiple pins were enabled at once (with `enableReceive(int interrupt)`), the interrupt handler for decoding signals was attached to both(/all) pins. But because interrupts must interface with the main program solely through global/static variables, and have no other information (e.g. callbacks), there is no way for the interrupt handler to know what pin actually triggered the interrupt. Therefore, when multiple pins were naïvely attached, noise from each pin--which would normally be filtered out--would be present, making it impossible to work with the data. There is the additional issue that the version of RCSwitch that Particle uses (repo [here](https://github.com/suda/RCSwitch)) is very out-of-date, which causes a few extra problems. The implementation of many functions is different from those in [the official version](https://github.com/sui77/rc-switch), there is missing support for many protocols, and the API is slightly different. For the official RCSwitch library, there have been attempts in the past to implement multiple-pin RX (see [here](https://github.com/sui77/rc-switch/issues/25) and [here](https://github.com/sui77/rc-switch/issues/63)), but none have been successful. I have opened [an issue](https://github.com/sui77/rc-switch/issues/71) detailing the changes needed to get multiple-pin RX actually working, but due to how behind the Particle library is, patching it into the official library is non-trivial (will either require porting or updating Particle's library to match the current official repo). # Solution To address this issue, the simplest solution is to separate the global/static data used in the interrupt handler into different sets per RX pin (create an array), and size it based off a `#define`d variable. (e.g. `#define RCSWITCH_MAX_RX_PINS 2`). This use of a macro `#define` is acceptable because the number of RX pins needed is something that changes infrequently and is well-known to the developer, and also because this library is intended as performant embedded code (e.g. for MCUs like the ATtiny). I refactored all the data used in the interrupt handler into a struct (`RCSwitch::InterruptData`). The static variables are then replaced with an array of these, one per RX pin (`RCSwitch::receiverInterrupts[RCSWITCH_MAX_RX_PINS]`). All of the code was simply extended to handle the array, and in most cases an additional parameter was added to specify which interrupt pin was intended. There is the issue of identifying each element of the array: I included a `RCSwitch::InterruptData.interrupt` member in the struct for this purpose. (`std::map` would be more straightforward but it is a lot of overhead.) There are also convenience functions which convert from array index to interrupt pin, and these functions should be inverses of the process since each pin can only be used for a single interrupt. (To actually perform the conversion, the array is simply searched for a matching interrupt pin. This is acceptable because `RCSWITCH_MAX_RX_PINS` should be small, and this search should have a negligible performance impact.) Another thing to note: functions might take arguments dealing with array index or interrupt pin, and these different arguments are differentiated with `int interrupt_i` and `int interrupt`, respectively. (Most of the functions taking `int interrupt_i` should be `private`.) I also added an additional member, `int nInterruptSourcePin`, which is updated with the last RX pin to go high. This can be used to fetch which pin triggered the interrupt. In the interrupt handler itself, the data (in the `RCSwitch::InterruptData` array) is tracked separately for each pin, with a new `isPinPrevHigh` member in the data struct. This ensures that the correct member of `RCSwitch::receiverInterrupts` is updated by the handler.

whc2001 · May 2, 2019, 2:31am

Thanks for your reply. Seems like it must be used with SparkIO Core, I might try to modify a standalone version of the library although the code seem a little bit complex.

whc2001 · May 3, 2019, 5:59am

OK I slightly modified the library to use it without Spark. It does allow to listen to multiple receivers, but you can only achieve that by stating multiple enableReceive() rather than instantiate more than one RCSwitch otherwise the ESP8266 would crash at any time. I made the example sketch to work and tested with my modules and transmitters. Now the only thing to do seems to be to add something like ZgatewayRFMulti.ino so that only one instance of RCSwitch is used to do the job.

1technophile · May 3, 2019, 6:44am

This seems very interesting. Thanks for the researchs. Indeed maybe we should remove ZgatewayRF315, keep only RF one and adapt it to handle both frequencies with the same instance of RCSwitch.

whc2001 · May 6, 2019, 9:39am

Successfully modified the source code to adapt for two RF modules (just a quick and dirty hack for two input and output, not extensible) and passed test on breadboard. Available here. I have already made a custom PCB (clicking will open Chinese version of EasyEDA) for it, after receiving it I will do more real-life testing.

Eno · March 15, 2020, 3:28pm

Did this ever get pulled into the main branch?

I tried this and a few other routes but couldn’t get both 315/433 to work together.

Tran_Vu_Linh · March 16, 2020, 2:24am

Maybe with cheap of esp8266, it is easier and safer to have 2 board for 315 and 433 seperately

whc2001 · March 16, 2020, 2:50am

Oh I have put aside that project since last year. When I go back to China in April (still TBD due to Corona) I will reinvestigate this topic and do more test.

Eno · April 20, 2020, 10:38am

Thanks. I hope you are keeping well; have you made it back yet?

It may be easier as mentioned to just have two esp boards given the cost/time on this but equally I quite like the neatness/simplicity of having it all driven from one.