STM8 about evofw3 HOT 28 CLOSED

On Thu, 26 Jan 2023 at 14:32, Peter Price ***@***.***> wrote: Good luck with that :-) The code has a lot of atmega specific code for the hardware interface. Because of the overhead the code doesn't use the Arduino IO functions but drives the GPIO pins directly via the registers. TX uses the SPI interface to fill the cc1101 TX fifo, but, because of the jitter on the incoming signals from the other devices, you can't use the cc1101 rx fifo to capture the data because it assumes everything is synchronous. If you try a port then I suggest you get the SPI interface to the CC1101 working first and then the HW UART interface between the STM and the CC1101. This is just an ISR triggered by the UART that reads the UART RX data into a buffer. If the STM hasn't got a HW UART available then you'll need to be good at coding. I suspect the STM8 HW UART has been connected to the host USB interface so this is going to be the case. The atmega328p SW UART code uses a HW interrupt to capture the timing of the signal edges and then a SW trap to process the captured data edges to generate an RX byte. This is very processor heavy and every cycle is critical to keep up with the data when it arrives. The SW UART won't work on an atmega clocked at less than 16MHz because there aren't enough instruction cycles available. The SW UART code is not as good at RXing radio messages as the HW UART code. Using a simple USB logic analyser ( e.g. https://www.amazon.co.uk/Hobby-Components-24MHz-Analyser-1-1-16/dp/B00DAYAREW) there are some debug lines still in the code that you can use to drive spare GPIO pins that will show you how much processor time you're using in the HW and SW ISR functions. The frame, message and host interface code should work without significant changes. That's all the help I can offer since I have zero STM knowledge. If you don't understand what I've said above give up now. — Reply to this email directly, view it on GitHub <#35 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AN4GHPSSWORQMO6CGL6XQV3WUKDJNANCNFSM6AAAAAAUHJSYXI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

On 26 Jan 2023, 15:04, at 15:04, pdbayes ***@***.***> wrote: Thanks for the advice. The dev board is this: https://www.ebyte.com/en/product-view-news.html?id=1691 All the UART side of things should be handled and I was hoping I would just have a stream of bits to deal with on the pi/pc. They say it comes with example software to do this but it is within a commercial IDE you have to pay for. It has a free trial so hopefully that will give me enough time to get it working. On Thu, 26 Jan 2023 at 14:32, Peter Price ***@***.***> wrote: > Good luck with that :-) > > The code has a lot of atmega specific code for the hardware interface. > Because of the overhead the code doesn't use the Arduino IO functions but > drives the GPIO pins directly via the registers. > > TX uses the SPI interface to fill the cc1101 TX fifo, but, because of the > jitter on the incoming signals from the other devices, you can't use the > cc1101 rx fifo to capture the data because it assumes everything is > synchronous. > > If you try a port then I suggest you get the SPI interface to the CC1101 > working first and then the HW UART interface between the STM and the > CC1101. This is just an ISR triggered by the UART that reads the UART RX > data into a buffer. > > If the STM hasn't got a HW UART available then you'll need to be good at > coding. I suspect the STM8 HW UART has been connected to the host USB > interface so this is going to be the case. > > The atmega328p SW UART code uses a HW interrupt to capture the timing of > the signal edges and then a SW trap to process the captured data edges to > generate an RX byte. This is very processor heavy and every cycle is > critical to keep up with the data when it arrives. The SW UART won't work > on an atmega clocked at less than 16MHz because there aren't enough > instruction cycles available. > > The SW UART code is not as good at RXing radio messages as the HW UART > code. > > Using a simple USB logic analyser ( e.g. > https://www.amazon.co.uk/Hobby-Components-24MHz-Analyser-1-1-16/dp/B00DAYAREW) > there are some debug lines still in the code that you can use to drive > spare GPIO pins that will show you how much processor time you're using in > the HW and SW ISR functions. > > The frame, message and host interface code should work without significant > changes. > > That's all the help I can offer since I have zero STM knowledge. > > If you don't understand what I've said above give up now. > > — > Reply to this email directly, view it on GitHub > <#35 (comment)>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AN4GHPSSWORQMO6CGL6XQV3WUKDJNANCNFSM6AAAAAAUHJSYXI> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> > -- Reply to this email directly or view it on GitHub: #35 (comment) You are receiving this because you commented. Message ID: ***@***.***>

On Thu, 26 Jan 2023, 18:22 Peter Price, ***@***.***> wrote: I think you've misunderstood about the UART in the context of evofw3. The bitstream that comes out of the cc1101 in an evohome environment has effectively been generated by UARTs in the Evo devices (controller, rad stats, thermostats etc) This means you need a UART interface in the STM8 facing the CC1101. On your Dev board the HW UART in the STM8 is almost certainly connected to the USB connector on the board. This means the connection to GDO0 and GD02 of the CC1101 will be using two ordinary GPIO signals. That means you have to implement a SW UART in the STM8 to decode the bitstream. You have to be able to synchronise with the stop/start bits in the bitstream so that you can identify and extract the real data. You are not dealing with a synchronous system. It's asynchronous because all the devices have their own clock and they're all slightly different. You're dealing with a bit stream at 38400 baud with significant jitter generated by some of the devices you are listening to. I very much doubt that the example software will get anywhere near extracting the data you need. ⁣Get BlueMail for Android ​ On 26 Jan 2023, 15:04, at 15:04, pdbayes ***@***.***> wrote: >Thanks for the advice. >The dev board is this: >https://www.ebyte.com/en/product-view-news.html?id=1691 >All the UART side of things should be handled and I was hoping I would >just >have a stream of bits to deal with on the pi/pc. They say it comes >with >example software to do this but it is within a commercial IDE you have >to >pay for. It has a free trial so hopefully that will give me enough time >to >get it working. > >On Thu, 26 Jan 2023 at 14:32, Peter Price ***@***.***> wrote: > >> Good luck with that :-) >> >> The code has a lot of atmega specific code for the hardware >interface. >> Because of the overhead the code doesn't use the Arduino IO functions >but >> drives the GPIO pins directly via the registers. >> >> TX uses the SPI interface to fill the cc1101 TX fifo, but, because of >the >> jitter on the incoming signals from the other devices, you can't use >the >> cc1101 rx fifo to capture the data because it assumes everything is >> synchronous. >> >> If you try a port then I suggest you get the SPI interface to the >CC1101 >> working first and then the HW UART interface between the STM and the >> CC1101. This is just an ISR triggered by the UART that reads the UART >RX >> data into a buffer. >> >> If the STM hasn't got a HW UART available then you'll need to be good >at >> coding. I suspect the STM8 HW UART has been connected to the host >USB >> interface so this is going to be the case. >> >> The atmega328p SW UART code uses a HW interrupt to capture the timing >of >> the signal edges and then a SW trap to process the captured data >edges to >> generate an RX byte. This is very processor heavy and every cycle is >> critical to keep up with the data when it arrives. The SW UART won't >work >> on an atmega clocked at less than 16MHz because there aren't enough >> instruction cycles available. >> >> The SW UART code is not as good at RXing radio messages as the HW >UART >> code. >> >> Using a simple USB logic analyser ( e.g. >> > https://www.amazon.co.uk/Hobby-Components-24MHz-Analyser-1-1-16/dp/B00DAYAREW ) >> there are some debug lines still in the code that you can use to >drive >> spare GPIO pins that will show you how much processor time you're >using in >> the HW and SW ISR functions. >> >> The frame, message and host interface code should work without >significant >> changes. >> >> That's all the help I can offer since I have zero STM knowledge. >> >> If you don't understand what I've said above give up now. >> >> — >> Reply to this email directly, view it on GitHub >> ><#35 (comment)>, >or >> unsubscribe >> >< https://github.com/notifications/unsubscribe-auth/AN4GHPSSWORQMO6CGL6XQV3WUKDJNANCNFSM6AAAAAAUHJSYXI > >> . >> You are receiving this because you authored the thread.Message ID: >> ***@***.***> >> > > >-- >Reply to this email directly or view it on GitHub: >#35 (comment) >You are receiving this because you commented. > >Message ID: ***@***.***> — Reply to this email directly, view it on GitHub <#35 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AN4GHPWOTGSC3DO2F7TN4M3WUK6FHANCNFSM6AAAAAAUHJSYXI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

On 26 Jan 2023, 20:00, at 20:00, pdbayes ***@***.***> wrote: Hmmm. I wonder if I could hard wire the GDO pins from the e07 module to an Arduino I have spare? Will depend on what the STM8 is doing on those pins or any intermediate components. Or maybe using software on the STM8 the recieved data could be sent as is to an io pin. On Thu, 26 Jan 2023, 18:22 Peter Price, ***@***.***> wrote: > I think you've misunderstood about the UART in the context of evofw3. > > The bitstream that comes out of the cc1101 in an evohome environment has > effectively been generated by UARTs in the Evo devices (controller, rad > stats, thermostats etc) > > This means you need a UART interface in the STM8 facing the CC1101. > > On your Dev board the HW UART in the STM8 is almost certainly connected to > the USB connector on the board. > > This means the connection to GDO0 and GD02 of the CC1101 will be using two > ordinary GPIO signals. That means you have to implement a SW UART in the > STM8 to decode the bitstream. You have to be able to synchronise with the > stop/start bits in the bitstream so that you can identify and extract the > real data. > > You are not dealing with a synchronous system. It's asynchronous because > all the devices have their own clock and they're all slightly different. > > You're dealing with a bit stream at 38400 baud with significant jitter > generated by some of the devices you are listening to. > > I very much doubt that the example software will get anywhere near > extracting the data you need. > > > > ⁣Get BlueMail for Android ​ > > On 26 Jan 2023, 15:04, at 15:04, pdbayes ***@***.***> wrote: > >Thanks for the advice. > >The dev board is this: > >https://www.ebyte.com/en/product-view-news.html?id=1691 > >All the UART side of things should be handled and I was hoping I would > >just > >have a stream of bits to deal with on the pi/pc. They say it comes > >with > >example software to do this but it is within a commercial IDE you have > >to > >pay for. It has a free trial so hopefully that will give me enough time > >to > >get it working. > > > >On Thu, 26 Jan 2023 at 14:32, Peter Price ***@***.***> wrote: > > > >> Good luck with that :-) > >> > >> The code has a lot of atmega specific code for the hardware > >interface. > >> Because of the overhead the code doesn't use the Arduino IO functions > >but > >> drives the GPIO pins directly via the registers. > >> > >> TX uses the SPI interface to fill the cc1101 TX fifo, but, because of > >the > >> jitter on the incoming signals from the other devices, you can't use > >the > >> cc1101 rx fifo to capture the data because it assumes everything is > >> synchronous. > >> > >> If you try a port then I suggest you get the SPI interface to the > >CC1101 > >> working first and then the HW UART interface between the STM and the > >> CC1101. This is just an ISR triggered by the UART that reads the UART > >RX > >> data into a buffer. > >> > >> If the STM hasn't got a HW UART available then you'll need to be good > >at > >> coding. I suspect the STM8 HW UART has been connected to the host > >USB > >> interface so this is going to be the case. > >> > >> The atmega328p SW UART code uses a HW interrupt to capture the timing > >of > >> the signal edges and then a SW trap to process the captured data > >edges to > >> generate an RX byte. This is very processor heavy and every cycle is > >> critical to keep up with the data when it arrives. The SW UART won't > >work > >> on an atmega clocked at less than 16MHz because there aren't enough > >> instruction cycles available. > >> > >> The SW UART code is not as good at RXing radio messages as the HW > >UART > >> code. > >> > >> Using a simple USB logic analyser ( e.g. > >> > > > https://www.amazon.co.uk/Hobby-Components-24MHz-Analyser-1-1-16/dp/B00DAYAREW > ) > >> there are some debug lines still in the code that you can use to > >drive > >> spare GPIO pins that will show you how much processor time you're > >using in > >> the HW and SW ISR functions. > >> > >> The frame, message and host interface code should work without > >significant > >> changes. > >> > >> That's all the help I can offer since I have zero STM knowledge. > >> > >> If you don't understand what I've said above give up now. > >> > >> — > >> Reply to this email directly, view it on GitHub > >> > ><#35 (comment)>, > >or > >> unsubscribe > >> > >< > https://github.com/notifications/unsubscribe-auth/AN4GHPSSWORQMO6CGL6XQV3WUKDJNANCNFSM6AAAAAAUHJSYXI > > > >> . > >> You are receiving this because you authored the thread.Message ID: > >> ***@***.***> > >> > > > > > >-- > >Reply to this email directly or view it on GitHub: > >#35 (comment) > >You are receiving this because you commented. > > > >Message ID: ***@***.***> > > — > Reply to this email directly, view it on GitHub > <#35 (comment)>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AN4GHPWOTGSC3DO2F7TN4M3WUK6FHANCNFSM6AAAAAAUHJSYXI> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> > -- Reply to this email directly or view it on GitHub: #35 (comment) You are receiving this because you commented. Message ID: ***@***.***>

On 26 Jan 2023, 22:00, at 22:00, Peter Price ***@***.***> wrote: If you have an Arduino with an atmega32u4 or a 16MHz atmega328p and you connect it correctly it will work with no code changes. If you only have an 8MHz atmega328p it won't. ⁣Get BlueMail for Android ​ On 26 Jan 2023, 20:00, at 20:00, pdbayes ***@***.***> wrote: >Hmmm. I wonder if I could hard wire the GDO pins from the e07 module to >an >Arduino I have spare? Will depend on what the STM8 is doing on those >pins >or any intermediate components. Or maybe using software on the STM8 >the >recieved data could be sent as is to an io pin. > >On Thu, 26 Jan 2023, 18:22 Peter Price, ***@***.***> wrote: > >> I think you've misunderstood about the UART in the context of >evofw3. >> >> The bitstream that comes out of the cc1101 in an evohome environment >has >> effectively been generated by UARTs in the Evo devices (controller, >rad >> stats, thermostats etc) >> >> This means you need a UART interface in the STM8 facing the CC1101. >> >> On your Dev board the HW UART in the STM8 is almost certainly >connected to >> the USB connector on the board. >> >> This means the connection to GDO0 and GD02 of the CC1101 will be >using two >> ordinary GPIO signals. That means you have to implement a SW UART in >the >> STM8 to decode the bitstream. You have to be able to synchronise >with the >> stop/start bits in the bitstream so that you can identify and extract >the >> real data. >> >> You are not dealing with a synchronous system. It's asynchronous >because >> all the devices have their own clock and they're all slightly >different. >> >> You're dealing with a bit stream at 38400 baud with significant >jitter >> generated by some of the devices you are listening to. >> >> I very much doubt that the example software will get anywhere near >> extracting the data you need. >> >> >> >> ⁣Get BlueMail for Android ​ >> >> On 26 Jan 2023, 15:04, at 15:04, pdbayes ***@***.***> wrote: >> >Thanks for the advice. >> >The dev board is this: >> >https://www.ebyte.com/en/product-view-news.html?id=1691 >> >All the UART side of things should be handled and I was hoping I >would >> >just >> >have a stream of bits to deal with on the pi/pc. They say it comes >> >with >> >example software to do this but it is within a commercial IDE you >have >> >to >> >pay for. It has a free trial so hopefully that will give me enough >time >> >to >> >get it working. >> > >> >On Thu, 26 Jan 2023 at 14:32, Peter Price ***@***.***> wrote: >> > >> >> Good luck with that :-) >> >> >> >> The code has a lot of atmega specific code for the hardware >> >interface. >> >> Because of the overhead the code doesn't use the Arduino IO >functions >> >but >> >> drives the GPIO pins directly via the registers. >> >> >> >> TX uses the SPI interface to fill the cc1101 TX fifo, but, because >of >> >the >> >> jitter on the incoming signals from the other devices, you can't >use >> >the >> >> cc1101 rx fifo to capture the data because it assumes everything >is >> >> synchronous. >> >> >> >> If you try a port then I suggest you get the SPI interface to the >> >CC1101 >> >> working first and then the HW UART interface between the STM and >the >> >> CC1101. This is just an ISR triggered by the UART that reads the >UART >> >RX >> >> data into a buffer. >> >> >> >> If the STM hasn't got a HW UART available then you'll need to be >good >> >at >> >> coding. I suspect the STM8 HW UART has been connected to the host >> >USB >> >> interface so this is going to be the case. >> >> >> >> The atmega328p SW UART code uses a HW interrupt to capture the >timing >> >of >> >> the signal edges and then a SW trap to process the captured data >> >edges to >> >> generate an RX byte. This is very processor heavy and every cycle >is >> >> critical to keep up with the data when it arrives. The SW UART >won't >> >work >> >> on an atmega clocked at less than 16MHz because there aren't >enough >> >> instruction cycles available. >> >> >> >> The SW UART code is not as good at RXing radio messages as the HW >> >UART >> >> code. >> >> >> >> Using a simple USB logic analyser ( e.g. >> >> >> > >> >https://www.amazon.co.uk/Hobby-Components-24MHz-Analyser-1-1-16/dp/B00DAYAREW >> ) >> >> there are some debug lines still in the code that you can use to >> >drive >> >> spare GPIO pins that will show you how much processor time you're >> >using in >> >> the HW and SW ISR functions. >> >> >> >> The frame, message and host interface code should work without >> >significant >> >> changes. >> >> >> >> That's all the help I can offer since I have zero STM knowledge. >> >> >> >> If you don't understand what I've said above give up now. >> >> >> >> — >> >> Reply to this email directly, view it on GitHub >> >> >> >><#35 (comment)>, >> >or >> >> unsubscribe >> >> >> >< >> >https://github.com/notifications/unsubscribe-auth/AN4GHPSSWORQMO6CGL6XQV3WUKDJNANCNFSM6AAAAAAUHJSYXI >> > >> >> . >> >> You are receiving this because you authored the thread.Message >ID: >> >> ***@***.***> >> >> >> > >> > >> >-- >> >Reply to this email directly or view it on GitHub: >> >#35 (comment) >> >You are receiving this because you commented. >> > >> >Message ID: ***@***.***> >> >> — >> Reply to this email directly, view it on GitHub >> ><#35 (comment)>, >or >> unsubscribe >> ><https://github.com/notifications/unsubscribe-auth/AN4GHPWOTGSC3DO2F7TN4M3WUK6FHANCNFSM6AAAAAAUHJSYXI> >> . >> You are receiving this because you authored the thread.Message ID: >> ***@***.***> >> > > >-- >Reply to this email directly or view it on GitHub: >#35 (comment) >You are receiving this because you commented. > >Message ID: ***@***.***>

On Thu, 26 Jan 2023, 22:06 Peter Price, ***@***.***> wrote: Just thought. The power to the e7 will have to come from the Arduino. It will also be connected to the STM8 so you need to be sure that it doesn't configure it's GOIOs in such a way that it interferes ⁣Get BlueMail for Android ​ On 26 Jan 2023, 22:00, at 22:00, Peter Price ***@***.***> wrote: >If you have an Arduino with an atmega32u4 or a 16MHz atmega328p and you >connect it correctly it will work with no code changes. > >If you only have an 8MHz atmega328p it won't. > >⁣Get BlueMail for Android ​ > >On 26 Jan 2023, 20:00, at 20:00, pdbayes ***@***.***> >wrote: >>Hmmm. I wonder if I could hard wire the GDO pins from the e07 module >to >>an >>Arduino I have spare? Will depend on what the STM8 is doing on those >>pins >>or any intermediate components. Or maybe using software on the STM8 >>the >>recieved data could be sent as is to an io pin. >> >>On Thu, 26 Jan 2023, 18:22 Peter Price, ***@***.***> wrote: >> >>> I think you've misunderstood about the UART in the context of >>evofw3. >>> >>> The bitstream that comes out of the cc1101 in an evohome environment >>has >>> effectively been generated by UARTs in the Evo devices (controller, >>rad >>> stats, thermostats etc) >>> >>> This means you need a UART interface in the STM8 facing the CC1101. >>> >>> On your Dev board the HW UART in the STM8 is almost certainly >>connected to >>> the USB connector on the board. >>> >>> This means the connection to GDO0 and GD02 of the CC1101 will be >>using two >>> ordinary GPIO signals. That means you have to implement a SW UART >in >>the >>> STM8 to decode the bitstream. You have to be able to synchronise >>with the >>> stop/start bits in the bitstream so that you can identify and >extract >>the >>> real data. >>> >>> You are not dealing with a synchronous system. It's asynchronous >>because >>> all the devices have their own clock and they're all slightly >>different. >>> >>> You're dealing with a bit stream at 38400 baud with significant >>jitter >>> generated by some of the devices you are listening to. >>> >>> I very much doubt that the example software will get anywhere near >>> extracting the data you need. >>> >>> >>> >>> ⁣Get BlueMail for Android ​ >>> >>> On 26 Jan 2023, 15:04, at 15:04, pdbayes ***@***.***> wrote: >>> >Thanks for the advice. >>> >The dev board is this: >>> >https://www.ebyte.com/en/product-view-news.html?id=1691 >>> >All the UART side of things should be handled and I was hoping I >>would >>> >just >>> >have a stream of bits to deal with on the pi/pc. They say it comes >>> >with >>> >example software to do this but it is within a commercial IDE you >>have >>> >to >>> >pay for. It has a free trial so hopefully that will give me enough >>time >>> >to >>> >get it working. >>> > >>> >On Thu, 26 Jan 2023 at 14:32, Peter Price ***@***.***> wrote: >>> > >>> >> Good luck with that :-) >>> >> >>> >> The code has a lot of atmega specific code for the hardware >>> >interface. >>> >> Because of the overhead the code doesn't use the Arduino IO >>functions >>> >but >>> >> drives the GPIO pins directly via the registers. >>> >> >>> >> TX uses the SPI interface to fill the cc1101 TX fifo, but, >because >>of >>> >the >>> >> jitter on the incoming signals from the other devices, you can't >>use >>> >the >>> >> cc1101 rx fifo to capture the data because it assumes everything >>is >>> >> synchronous. >>> >> >>> >> If you try a port then I suggest you get the SPI interface to the >>> >CC1101 >>> >> working first and then the HW UART interface between the STM and >>the >>> >> CC1101. This is just an ISR triggered by the UART that reads the >>UART >>> >RX >>> >> data into a buffer. >>> >> >>> >> If the STM hasn't got a HW UART available then you'll need to be >>good >>> >at >>> >> coding. I suspect the STM8 HW UART has been connected to the host >>> >USB >>> >> interface so this is going to be the case. >>> >> >>> >> The atmega328p SW UART code uses a HW interrupt to capture the >>timing >>> >of >>> >> the signal edges and then a SW trap to process the captured data >>> >edges to >>> >> generate an RX byte. This is very processor heavy and every cycle >>is >>> >> critical to keep up with the data when it arrives. The SW UART >>won't >>> >work >>> >> on an atmega clocked at less than 16MHz because there aren't >>enough >>> >> instruction cycles available. >>> >> >>> >> The SW UART code is not as good at RXing radio messages as the HW >>> >UART >>> >> code. >>> >> >>> >> Using a simple USB logic analyser ( e.g. >>> >> >>> > >>> >> https://www.amazon.co.uk/Hobby-Components-24MHz-Analyser-1-1-16/dp/B00DAYAREW >>> ) >>> >> there are some debug lines still in the code that you can use to >>> >drive >>> >> spare GPIO pins that will show you how much processor time you're >>> >using in >>> >> the HW and SW ISR functions. >>> >> >>> >> The frame, message and host interface code should work without >>> >significant >>> >> changes. >>> >> >>> >> That's all the help I can offer since I have zero STM knowledge. >>> >> >>> >> If you don't understand what I've said above give up now. >>> >> >>> >> — >>> >> Reply to this email directly, view it on GitHub >>> >> >>> >>><#35 (comment)>, >>> >or >>> >> unsubscribe >>> >> >>> >< >>> >> https://github.com/notifications/unsubscribe-auth/AN4GHPSSWORQMO6CGL6XQV3WUKDJNANCNFSM6AAAAAAUHJSYXI >>> > >>> >> . >>> >> You are receiving this because you authored the thread.Message >>ID: >>> >> ***@***.***> >>> >> >>> > >>> > >>> >-- >>> >Reply to this email directly or view it on GitHub: >>> >#35 (comment) >>> >You are receiving this because you commented. >>> > >>> >Message ID: ***@***.***> >>> >>> — >>> Reply to this email directly, view it on GitHub >>> >><#35 (comment)>, >>or >>> unsubscribe >>> >>< https://github.com/notifications/unsubscribe-auth/AN4GHPWOTGSC3DO2F7TN4M3WUK6FHANCNFSM6AAAAAAUHJSYXI > >>> . >>> You are receiving this because you authored the thread.Message ID: >>> ***@***.***> >>> >> >> >>-- >>Reply to this email directly or view it on GitHub: >>#35 (comment) >>You are receiving this because you commented. >> >>Message ID: ***@***.***> — Reply to this email directly, view it on GitHub <#35 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AN4GHPWDEQVBRFCQWOYLZOLWULYNPANCNFSM6AAAAAAUHJSYXI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

On Fri, 27 Jan 2023, 06:57 Paul Bayes, ***@***.***> wrote: I have an Uno so should be ok. Thanks for your help On Thu, 26 Jan 2023, 22:06 Peter Price, ***@***.***> wrote: > Just thought. > > The power to the e7 will have to come from the Arduino. > > It will also be connected to the STM8 so you need to be sure that it > doesn't configure it's GOIOs in such a way that it interferes > > ⁣Get BlueMail for Android ​ > > On 26 Jan 2023, 22:00, at 22:00, Peter Price ***@***.***> wrote: > >If you have an Arduino with an atmega32u4 or a 16MHz atmega328p and you > >connect it correctly it will work with no code changes. > > > >If you only have an 8MHz atmega328p it won't. > > > >⁣Get BlueMail for Android ​ > > > >On 26 Jan 2023, 20:00, at 20:00, pdbayes ***@***.***> > >wrote: > >>Hmmm. I wonder if I could hard wire the GDO pins from the e07 module > >to > >>an > >>Arduino I have spare? Will depend on what the STM8 is doing on those > >>pins > >>or any intermediate components. Or maybe using software on the STM8 > >>the > >>recieved data could be sent as is to an io pin. > >> > >>On Thu, 26 Jan 2023, 18:22 Peter Price, ***@***.***> wrote: > >> > >>> I think you've misunderstood about the UART in the context of > >>evofw3. > >>> > >>> The bitstream that comes out of the cc1101 in an evohome environment > >>has > >>> effectively been generated by UARTs in the Evo devices (controller, > >>rad > >>> stats, thermostats etc) > >>> > >>> This means you need a UART interface in the STM8 facing the CC1101. > >>> > >>> On your Dev board the HW UART in the STM8 is almost certainly > >>connected to > >>> the USB connector on the board. > >>> > >>> This means the connection to GDO0 and GD02 of the CC1101 will be > >>using two > >>> ordinary GPIO signals. That means you have to implement a SW UART > >in > >>the > >>> STM8 to decode the bitstream. You have to be able to synchronise > >>with the > >>> stop/start bits in the bitstream so that you can identify and > >extract > >>the > >>> real data. > >>> > >>> You are not dealing with a synchronous system. It's asynchronous > >>because > >>> all the devices have their own clock and they're all slightly > >>different. > >>> > >>> You're dealing with a bit stream at 38400 baud with significant > >>jitter > >>> generated by some of the devices you are listening to. > >>> > >>> I very much doubt that the example software will get anywhere near > >>> extracting the data you need. > >>> > >>> > >>> > >>> ⁣Get BlueMail for Android ​ > >>> > >>> On 26 Jan 2023, 15:04, at 15:04, pdbayes ***@***.***> wrote: > >>> >Thanks for the advice. > >>> >The dev board is this: > >>> >https://www.ebyte.com/en/product-view-news.html?id=1691 > >>> >All the UART side of things should be handled and I was hoping I > >>would > >>> >just > >>> >have a stream of bits to deal with on the pi/pc. They say it comes > >>> >with > >>> >example software to do this but it is within a commercial IDE you > >>have > >>> >to > >>> >pay for. It has a free trial so hopefully that will give me enough > >>time > >>> >to > >>> >get it working. > >>> > > >>> >On Thu, 26 Jan 2023 at 14:32, Peter Price ***@***.***> wrote: > >>> > > >>> >> Good luck with that :-) > >>> >> > >>> >> The code has a lot of atmega specific code for the hardware > >>> >interface. > >>> >> Because of the overhead the code doesn't use the Arduino IO > >>functions > >>> >but > >>> >> drives the GPIO pins directly via the registers. > >>> >> > >>> >> TX uses the SPI interface to fill the cc1101 TX fifo, but, > >because > >>of > >>> >the > >>> >> jitter on the incoming signals from the other devices, you can't > >>use > >>> >the > >>> >> cc1101 rx fifo to capture the data because it assumes everything > >>is > >>> >> synchronous. > >>> >> > >>> >> If you try a port then I suggest you get the SPI interface to the > >>> >CC1101 > >>> >> working first and then the HW UART interface between the STM and > >>the > >>> >> CC1101. This is just an ISR triggered by the UART that reads the > >>UART > >>> >RX > >>> >> data into a buffer. > >>> >> > >>> >> If the STM hasn't got a HW UART available then you'll need to be > >>good > >>> >at > >>> >> coding. I suspect the STM8 HW UART has been connected to the host > >>> >USB > >>> >> interface so this is going to be the case. > >>> >> > >>> >> The atmega328p SW UART code uses a HW interrupt to capture the > >>timing > >>> >of > >>> >> the signal edges and then a SW trap to process the captured data > >>> >edges to > >>> >> generate an RX byte. This is very processor heavy and every cycle > >>is > >>> >> critical to keep up with the data when it arrives. The SW UART > >>won't > >>> >work > >>> >> on an atmega clocked at less than 16MHz because there aren't > >>enough > >>> >> instruction cycles available. > >>> >> > >>> >> The SW UART code is not as good at RXing radio messages as the HW > >>> >UART > >>> >> code. > >>> >> > >>> >> Using a simple USB logic analyser ( e.g. > >>> >> > >>> > > >>> > >> > https://www.amazon.co.uk/Hobby-Components-24MHz-Analyser-1-1-16/dp/B00DAYAREW > >>> ) > >>> >> there are some debug lines still in the code that you can use to > >>> >drive > >>> >> spare GPIO pins that will show you how much processor time you're > >>> >using in > >>> >> the HW and SW ISR functions. > >>> >> > >>> >> The frame, message and host interface code should work without > >>> >significant > >>> >> changes. > >>> >> > >>> >> That's all the help I can offer since I have zero STM knowledge. > >>> >> > >>> >> If you don't understand what I've said above give up now. > >>> >> > >>> >> — > >>> >> Reply to this email directly, view it on GitHub > >>> >> > >>> > >>><#35 (comment)>, > >>> >or > >>> >> unsubscribe > >>> >> > >>> >< > >>> > >> > https://github.com/notifications/unsubscribe-auth/AN4GHPSSWORQMO6CGL6XQV3WUKDJNANCNFSM6AAAAAAUHJSYXI > >>> > > >>> >> . > >>> >> You are receiving this because you authored the thread.Message > >>ID: > >>> >> ***@***.***> > >>> >> > >>> > > >>> > > >>> >-- > >>> >Reply to this email directly or view it on GitHub: > >>> >#35 (comment) > >>> >You are receiving this because you commented. > >>> > > >>> >Message ID: ***@***.***> > >>> > >>> — > >>> Reply to this email directly, view it on GitHub > >>> > >><#35 (comment)>, > >>or > >>> unsubscribe > >>> > >>< > https://github.com/notifications/unsubscribe-auth/AN4GHPWOTGSC3DO2F7TN4M3WUK6FHANCNFSM6AAAAAAUHJSYXI > > > >>> . > >>> You are receiving this because you authored the thread.Message ID: > >>> ***@***.***> > >>> > >> > >> > >>-- > >>Reply to this email directly or view it on GitHub: > >>#35 (comment) > >>You are receiving this because you commented. > >> > >>Message ID: ***@***.***> > > — > Reply to this email directly, view it on GitHub > <#35 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AN4GHPWDEQVBRFCQWOYLZOLWULYNPANCNFSM6AAAAAAUHJSYXI> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

On 28 Jan 2023, 16:08, at 16:08, pdbayes ***@***.***> wrote: Last question I promise. I have a different recover now with no MCU. Which MCU have you found works best. I have an old cloned Nano but It won't load the sketch. I think it has a Chinese rip off usb chip that's not great and that is causing issues. Would the latest Nano be a good choice. On Fri, 27 Jan 2023, 06:57 Paul Bayes, ***@***.***> wrote: > I have an Uno so should be ok. Thanks for your help > > On Thu, 26 Jan 2023, 22:06 Peter Price, ***@***.***> wrote: > >> Just thought. >> >> The power to the e7 will have to come from the Arduino. >> >> It will also be connected to the STM8 so you need to be sure that it >> doesn't configure it's GOIOs in such a way that it interferes >> >> ⁣Get BlueMail for Android ​ >> >> On 26 Jan 2023, 22:00, at 22:00, Peter Price ***@***.***> wrote: >> >If you have an Arduino with an atmega32u4 or a 16MHz atmega328p and you >> >connect it correctly it will work with no code changes. >> > >> >If you only have an 8MHz atmega328p it won't. >> > >> >⁣Get BlueMail for Android ​ >> > >> >On 26 Jan 2023, 20:00, at 20:00, pdbayes ***@***.***> >> >wrote: >> >>Hmmm. I wonder if I could hard wire the GDO pins from the e07 module >> >to >> >>an >> >>Arduino I have spare? Will depend on what the STM8 is doing on those >> >>pins >> >>or any intermediate components. Or maybe using software on the STM8 >> >>the >> >>recieved data could be sent as is to an io pin. >> >> >> >>On Thu, 26 Jan 2023, 18:22 Peter Price, ***@***.***> wrote: >> >> >> >>> I think you've misunderstood about the UART in the context of >> >>evofw3. >> >>> >> >>> The bitstream that comes out of the cc1101 in an evohome environment >> >>has >> >>> effectively been generated by UARTs in the Evo devices (controller, >> >>rad >> >>> stats, thermostats etc) >> >>> >> >>> This means you need a UART interface in the STM8 facing the CC1101. >> >>> >> >>> On your Dev board the HW UART in the STM8 is almost certainly >> >>connected to >> >>> the USB connector on the board. >> >>> >> >>> This means the connection to GDO0 and GD02 of the CC1101 will be >> >>using two >> >>> ordinary GPIO signals. That means you have to implement a SW UART >> >in >> >>the >> >>> STM8 to decode the bitstream. You have to be able to synchronise >> >>with the >> >>> stop/start bits in the bitstream so that you can identify and >> >extract >> >>the >> >>> real data. >> >>> >> >>> You are not dealing with a synchronous system. It's asynchronous >> >>because >> >>> all the devices have their own clock and they're all slightly >> >>different. >> >>> >> >>> You're dealing with a bit stream at 38400 baud with significant >> >>jitter >> >>> generated by some of the devices you are listening to. >> >>> >> >>> I very much doubt that the example software will get anywhere near >> >>> extracting the data you need. >> >>> >> >>> >> >>> >> >>> ⁣Get BlueMail for Android ​ >> >>> >> >>> On 26 Jan 2023, 15:04, at 15:04, pdbayes ***@***.***> wrote: >> >>> >Thanks for the advice. >> >>> >The dev board is this: >> >>> >https://www.ebyte.com/en/product-view-news.html?id=1691 >> >>> >All the UART side of things should be handled and I was hoping I >> >>would >> >>> >just >> >>> >have a stream of bits to deal with on the pi/pc. They say it comes >> >>> >with >> >>> >example software to do this but it is within a commercial IDE you >> >>have >> >>> >to >> >>> >pay for. It has a free trial so hopefully that will give me enough >> >>time >> >>> >to >> >>> >get it working. >> >>> > >> >>> >On Thu, 26 Jan 2023 at 14:32, Peter Price ***@***.***> wrote: >> >>> > >> >>> >> Good luck with that :-) >> >>> >> >> >>> >> The code has a lot of atmega specific code for the hardware >> >>> >interface. >> >>> >> Because of the overhead the code doesn't use the Arduino IO >> >>functions >> >>> >but >> >>> >> drives the GPIO pins directly via the registers. >> >>> >> >> >>> >> TX uses the SPI interface to fill the cc1101 TX fifo, but, >> >because >> >>of >> >>> >the >> >>> >> jitter on the incoming signals from the other devices, you can't >> >>use >> >>> >the >> >>> >> cc1101 rx fifo to capture the data because it assumes everything >> >>is >> >>> >> synchronous. >> >>> >> >> >>> >> If you try a port then I suggest you get the SPI interface to the >> >>> >CC1101 >> >>> >> working first and then the HW UART interface between the STM and >> >>the >> >>> >> CC1101. This is just an ISR triggered by the UART that reads the >> >>UART >> >>> >RX >> >>> >> data into a buffer. >> >>> >> >> >>> >> If the STM hasn't got a HW UART available then you'll need to be >> >>good >> >>> >at >> >>> >> coding. I suspect the STM8 HW UART has been connected to the host >> >>> >USB >> >>> >> interface so this is going to be the case. >> >>> >> >> >>> >> The atmega328p SW UART code uses a HW interrupt to capture the >> >>timing >> >>> >of >> >>> >> the signal edges and then a SW trap to process the captured data >> >>> >edges to >> >>> >> generate an RX byte. This is very processor heavy and every cycle >> >>is >> >>> >> critical to keep up with the data when it arrives. The SW UART >> >>won't >> >>> >work >> >>> >> on an atmega clocked at less than 16MHz because there aren't >> >>enough >> >>> >> instruction cycles available. >> >>> >> >> >>> >> The SW UART code is not as good at RXing radio messages as the HW >> >>> >UART >> >>> >> code. >> >>> >> >> >>> >> Using a simple USB logic analyser ( e.g. >> >>> >> >> >>> > >> >>> >> >> >> https://www.amazon.co.uk/Hobby-Components-24MHz-Analyser-1-1-16/dp/B00DAYAREW >> >>> ) >> >>> >> there are some debug lines still in the code that you can use to >> >>> >drive >> >>> >> spare GPIO pins that will show you how much processor time you're >> >>> >using in >> >>> >> the HW and SW ISR functions. >> >>> >> >> >>> >> The frame, message and host interface code should work without >> >>> >significant >> >>> >> changes. >> >>> >> >> >>> >> That's all the help I can offer since I have zero STM knowledge. >> >>> >> >> >>> >> If you don't understand what I've said above give up now. >> >>> >> >> >>> >> — >> >>> >> Reply to this email directly, view it on GitHub >> >>> >> >> >>> >> >>><#35 (comment)>, >> >>> >or >> >>> >> unsubscribe >> >>> >> >> >>> >< >> >>> >> >> >> https://github.com/notifications/unsubscribe-auth/AN4GHPSSWORQMO6CGL6XQV3WUKDJNANCNFSM6AAAAAAUHJSYXI >> >>> > >> >>> >> . >> >>> >> You are receiving this because you authored the thread.Message >> >>ID: >> >>> >> ***@***.***> >> >>> >> >> >>> > >> >>> > >> >>> >-- >> >>> >Reply to this email directly or view it on GitHub: >> >>> >#35 (comment) >> >>> >You are receiving this because you commented. >> >>> > >> >>> >Message ID: ***@***.***> >> >>> >> >>> — >> >>> Reply to this email directly, view it on GitHub >> >>> >> >><#35 (comment)>, >> >>or >> >>> unsubscribe >> >>> >> >>< >> https://github.com/notifications/unsubscribe-auth/AN4GHPWOTGSC3DO2F7TN4M3WUK6FHANCNFSM6AAAAAAUHJSYXI >> > >> >>> . >> >>> You are receiving this because you authored the thread.Message ID: >> >>> ***@***.***> >> >>> >> >> >> >> >> >>-- >> >>Reply to this email directly or view it on GitHub: >> >>#35 (comment) >> >>You are receiving this because you commented. >> >> >> >>Message ID: ***@***.***> >> >> — >> Reply to this email directly, view it on GitHub >> <#35 (comment)>, >> or unsubscribe >> <https://github.com/notifications/unsubscribe-auth/AN4GHPWDEQVBRFCQWOYLZOLWULYNPANCNFSM6AAAAAAUHJSYXI> >> . >> You are receiving this because you authored the thread.Message ID: >> ***@***.***> >> > -- Reply to this email directly or view it on GitHub: #35 (comment) You are receiving this because you commented. Message ID: ***@***.***>

On Sat, 28 Jan 2023, 18:06 Peter Price, ***@***.***> wrote: You want something with an atmega32u4 processor. This will have a direct usb interface to the host (no driver required) and leaves the HW UART free to connect to the CC1101. Avoid atmega328 based devices. When you have it let me know exactly what you have and I'll tell you the connections you need. ⁣Get BlueMail for Android ​ On 28 Jan 2023, 16:08, at 16:08, pdbayes ***@***.***> wrote: >Last question I promise. I have a different recover now with no MCU. >Which >MCU have you found works best. I have an old cloned Nano but It won't >load >the sketch. I think it has a Chinese rip off usb chip that's not great >and >that is causing issues. Would the latest Nano be a good choice. > >On Fri, 27 Jan 2023, 06:57 Paul Bayes, ***@***.***> wrote: > >> I have an Uno so should be ok. Thanks for your help >> >> On Thu, 26 Jan 2023, 22:06 Peter Price, ***@***.***> wrote: >> >>> Just thought. >>> >>> The power to the e7 will have to come from the Arduino. >>> >>> It will also be connected to the STM8 so you need to be sure that >it >>> doesn't configure it's GOIOs in such a way that it interferes >>> >>> ⁣Get BlueMail for Android ​ >>> >>> On 26 Jan 2023, 22:00, at 22:00, Peter Price ***@***.***> wrote: >>> >If you have an Arduino with an atmega32u4 or a 16MHz atmega328p and >you >>> >connect it correctly it will work with no code changes. >>> > >>> >If you only have an 8MHz atmega328p it won't. >>> > >>> >⁣Get BlueMail for Android ​ >>> > >>> >On 26 Jan 2023, 20:00, at 20:00, pdbayes ***@***.***> >>> >wrote: >>> >>Hmmm. I wonder if I could hard wire the GDO pins from the e07 >module >>> >to >>> >>an >>> >>Arduino I have spare? Will depend on what the STM8 is doing on >those >>> >>pins >>> >>or any intermediate components. Or maybe using software on the >STM8 >>> >>the >>> >>recieved data could be sent as is to an io pin. >>> >> >>> >>On Thu, 26 Jan 2023, 18:22 Peter Price, ***@***.***> wrote: >>> >> >>> >>> I think you've misunderstood about the UART in the context of >>> >>evofw3. >>> >>> >>> >>> The bitstream that comes out of the cc1101 in an evohome >environment >>> >>has >>> >>> effectively been generated by UARTs in the Evo devices >(controller, >>> >>rad >>> >>> stats, thermostats etc) >>> >>> >>> >>> This means you need a UART interface in the STM8 facing the >CC1101. >>> >>> >>> >>> On your Dev board the HW UART in the STM8 is almost certainly >>> >>connected to >>> >>> the USB connector on the board. >>> >>> >>> >>> This means the connection to GDO0 and GD02 of the CC1101 will >be >>> >>using two >>> >>> ordinary GPIO signals. That means you have to implement a SW >UART >>> >in >>> >>the >>> >>> STM8 to decode the bitstream. You have to be able to >synchronise >>> >>with the >>> >>> stop/start bits in the bitstream so that you can identify and >>> >extract >>> >>the >>> >>> real data. >>> >>> >>> >>> You are not dealing with a synchronous system. It's >asynchronous >>> >>because >>> >>> all the devices have their own clock and they're all slightly >>> >>different. >>> >>> >>> >>> You're dealing with a bit stream at 38400 baud with significant >>> >>jitter >>> >>> generated by some of the devices you are listening to. >>> >>> >>> >>> I very much doubt that the example software will get anywhere >near >>> >>> extracting the data you need. >>> >>> >>> >>> >>> >>> >>> >>> ⁣Get BlueMail for Android ​ >>> >>> >>> >>> On 26 Jan 2023, 15:04, at 15:04, pdbayes ***@***.***> wrote: >>> >>> >Thanks for the advice. >>> >>> >The dev board is this: >>> >>> >https://www.ebyte.com/en/product-view-news.html?id=1691 >>> >>> >All the UART side of things should be handled and I was hoping >I >>> >>would >>> >>> >just >>> >>> >have a stream of bits to deal with on the pi/pc. They say it >comes >>> >>> >with >>> >>> >example software to do this but it is within a commercial IDE >you >>> >>have >>> >>> >to >>> >>> >pay for. It has a free trial so hopefully that will give me >enough >>> >>time >>> >>> >to >>> >>> >get it working. >>> >>> > >>> >>> >On Thu, 26 Jan 2023 at 14:32, Peter Price ***@***.***> wrote: >>> >>> > >>> >>> >> Good luck with that :-) >>> >>> >> >>> >>> >> The code has a lot of atmega specific code for the hardware >>> >>> >interface. >>> >>> >> Because of the overhead the code doesn't use the Arduino IO >>> >>functions >>> >>> >but >>> >>> >> drives the GPIO pins directly via the registers. >>> >>> >> >>> >>> >> TX uses the SPI interface to fill the cc1101 TX fifo, but, >>> >because >>> >>of >>> >>> >the >>> >>> >> jitter on the incoming signals from the other devices, you >can't >>> >>use >>> >>> >the >>> >>> >> cc1101 rx fifo to capture the data because it assumes >everything >>> >>is >>> >>> >> synchronous. >>> >>> >> >>> >>> >> If you try a port then I suggest you get the SPI interface to >the >>> >>> >CC1101 >>> >>> >> working first and then the HW UART interface between the STM >and >>> >>the >>> >>> >> CC1101. This is just an ISR triggered by the UART that reads >the >>> >>UART >>> >>> >RX >>> >>> >> data into a buffer. >>> >>> >> >>> >>> >> If the STM hasn't got a HW UART available then you'll need to >be >>> >>good >>> >>> >at >>> >>> >> coding. I suspect the STM8 HW UART has been connected to the >host >>> >>> >USB >>> >>> >> interface so this is going to be the case. >>> >>> >> >>> >>> >> The atmega328p SW UART code uses a HW interrupt to capture >the >>> >>timing >>> >>> >of >>> >>> >> the signal edges and then a SW trap to process the captured >data >>> >>> >edges to >>> >>> >> generate an RX byte. This is very processor heavy and every >cycle >>> >>is >>> >>> >> critical to keep up with the data when it arrives. The SW >UART >>> >>won't >>> >>> >work >>> >>> >> on an atmega clocked at less than 16MHz because there aren't >>> >>enough >>> >>> >> instruction cycles available. >>> >>> >> >>> >>> >> The SW UART code is not as good at RXing radio messages as >the HW >>> >>> >UART >>> >>> >> code. >>> >>> >> >>> >>> >> Using a simple USB logic analyser ( e.g. >>> >>> >> >>> >>> > >>> >>> >>> >> >>> > https://www.amazon.co.uk/Hobby-Components-24MHz-Analyser-1-1-16/dp/B00DAYAREW >>> >>> ) >>> >>> >> there are some debug lines still in the code that you can use >to >>> >>> >drive >>> >>> >> spare GPIO pins that will show you how much processor time >you're >>> >>> >using in >>> >>> >> the HW and SW ISR functions. >>> >>> >> >>> >>> >> The frame, message and host interface code should work >without >>> >>> >significant >>> >>> >> changes. >>> >>> >> >>> >>> >> That's all the help I can offer since I have zero STM >knowledge. >>> >>> >> >>> >>> >> If you don't understand what I've said above give up now. >>> >>> >> >>> >>> >> — >>> >>> >> Reply to this email directly, view it on GitHub >>> >>> >> >>> >>> >>> >>>><#35 (comment)>, >>> >>> >or >>> >>> >> unsubscribe >>> >>> >> >>> >>> >< >>> >>> >>> >> >>> > https://github.com/notifications/unsubscribe-auth/AN4GHPSSWORQMO6CGL6XQV3WUKDJNANCNFSM6AAAAAAUHJSYXI >>> >>> > >>> >>> >> . >>> >>> >> You are receiving this because you authored the >thread.Message >>> >>ID: >>> >>> >> ***@***.***> >>> >>> >> >>> >>> > >>> >>> > >>> >>> >-- >>> >>> >Reply to this email directly or view it on GitHub: >>> >>> >>#35 (comment) >>> >>> >You are receiving this because you commented. >>> >>> > >>> >>> >Message ID: ***@***.***> >>> >>> >>> >>> — >>> >>> Reply to this email directly, view it on GitHub >>> >>> >>> >>><#35 (comment)>, >>> >>or >>> >>> unsubscribe >>> >>> >>> >>< >>> > https://github.com/notifications/unsubscribe-auth/AN4GHPWOTGSC3DO2F7TN4M3WUK6FHANCNFSM6AAAAAAUHJSYXI >>> > >>> >>> . >>> >>> You are receiving this because you authored the thread.Message >ID: >>> >>> ***@***.***> >>> >>> >>> >> >>> >> >>> >>-- >>> >>Reply to this email directly or view it on GitHub: >>> >>>#35 (comment) >>> >>You are receiving this because you commented. >>> >> >>> >>Message ID: ***@***.***> >>> >>> — >>> Reply to this email directly, view it on GitHub >>> ><#35 (comment)>, >>> or unsubscribe >>> >< https://github.com/notifications/unsubscribe-auth/AN4GHPWDEQVBRFCQWOYLZOLWULYNPANCNFSM6AAAAAAUHJSYXI > >>> . >>> You are receiving this because you authored the thread.Message ID: >>> ***@***.***> >>> >> > > >-- >Reply to this email directly or view it on GitHub: >#35 (comment) >You are receiving this because you commented. > >Message ID: ***@***.***> — Reply to this email directly, view it on GitHub <#35 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AN4GHPWNBGQWDHVC25NK6GLWUVN2ZANCNFSM6AAAAAAUHJSYXI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

On Sat, 28 Jan 2023, 19:18 Paul Bayes, ***@***.***> wrote: Thanks. I've ordered a Leonardo as I have a prototype shield in this format, which might help keep things tidy. On Sat, 28 Jan 2023, 18:06 Peter Price, ***@***.***> wrote: > You want something with an atmega32u4 processor. This will have a direct > usb interface to the host (no driver required) and leaves the HW UART free > to connect to the CC1101. > > Avoid atmega328 based devices. > > When you have it let me know exactly what you have and I'll tell you the > connections you need. > > ⁣Get BlueMail for Android ​ > > On 28 Jan 2023, 16:08, at 16:08, pdbayes ***@***.***> wrote: > >Last question I promise. I have a different recover now with no MCU. > >Which > >MCU have you found works best. I have an old cloned Nano but It won't > >load > >the sketch. I think it has a Chinese rip off usb chip that's not great > >and > >that is causing issues. Would the latest Nano be a good choice. > > > >On Fri, 27 Jan 2023, 06:57 Paul Bayes, ***@***.***> wrote: > > > >> I have an Uno so should be ok. Thanks for your help > >> > >> On Thu, 26 Jan 2023, 22:06 Peter Price, ***@***.***> wrote: > >> > >>> Just thought. > >>> > >>> The power to the e7 will have to come from the Arduino. > >>> > >>> It will also be connected to the STM8 so you need to be sure that > >it > >>> doesn't configure it's GOIOs in such a way that it interferes > >>> > >>> ⁣Get BlueMail for Android ​ > >>> > >>> On 26 Jan 2023, 22:00, at 22:00, Peter Price ***@***.***> wrote: > >>> >If you have an Arduino with an atmega32u4 or a 16MHz atmega328p and > >you > >>> >connect it correctly it will work with no code changes. > >>> > > >>> >If you only have an 8MHz atmega328p it won't. > >>> > > >>> >⁣Get BlueMail for Android ​ > >>> > > >>> >On 26 Jan 2023, 20:00, at 20:00, pdbayes ***@***.***> > >>> >wrote: > >>> >>Hmmm. I wonder if I could hard wire the GDO pins from the e07 > >module > >>> >to > >>> >>an > >>> >>Arduino I have spare? Will depend on what the STM8 is doing on > >those > >>> >>pins > >>> >>or any intermediate components. Or maybe using software on the > >STM8 > >>> >>the > >>> >>recieved data could be sent as is to an io pin. > >>> >> > >>> >>On Thu, 26 Jan 2023, 18:22 Peter Price, ***@***.***> wrote: > >>> >> > >>> >>> I think you've misunderstood about the UART in the context of > >>> >>evofw3. > >>> >>> > >>> >>> The bitstream that comes out of the cc1101 in an evohome > >environment > >>> >>has > >>> >>> effectively been generated by UARTs in the Evo devices > >(controller, > >>> >>rad > >>> >>> stats, thermostats etc) > >>> >>> > >>> >>> This means you need a UART interface in the STM8 facing the > >CC1101. > >>> >>> > >>> >>> On your Dev board the HW UART in the STM8 is almost certainly > >>> >>connected to > >>> >>> the USB connector on the board. > >>> >>> > >>> >>> This means the connection to GDO0 and GD02 of the CC1101 will > >be > >>> >>using two > >>> >>> ordinary GPIO signals. That means you have to implement a SW > >UART > >>> >in > >>> >>the > >>> >>> STM8 to decode the bitstream. You have to be able to > >synchronise > >>> >>with the > >>> >>> stop/start bits in the bitstream so that you can identify and > >>> >extract > >>> >>the > >>> >>> real data. > >>> >>> > >>> >>> You are not dealing with a synchronous system. It's > >asynchronous > >>> >>because > >>> >>> all the devices have their own clock and they're all slightly > >>> >>different. > >>> >>> > >>> >>> You're dealing with a bit stream at 38400 baud with significant > >>> >>jitter > >>> >>> generated by some of the devices you are listening to. > >>> >>> > >>> >>> I very much doubt that the example software will get anywhere > >near > >>> >>> extracting the data you need. > >>> >>> > >>> >>> > >>> >>> > >>> >>> ⁣Get BlueMail for Android ​ > >>> >>> > >>> >>> On 26 Jan 2023, 15:04, at 15:04, pdbayes ***@***.***> wrote: > >>> >>> >Thanks for the advice. > >>> >>> >The dev board is this: > >>> >>> >https://www.ebyte.com/en/product-view-news.html?id=1691 > >>> >>> >All the UART side of things should be handled and I was hoping > >I > >>> >>would > >>> >>> >just > >>> >>> >have a stream of bits to deal with on the pi/pc. They say it > >comes > >>> >>> >with > >>> >>> >example software to do this but it is within a commercial IDE > >you > >>> >>have > >>> >>> >to > >>> >>> >pay for. It has a free trial so hopefully that will give me > >enough > >>> >>time > >>> >>> >to > >>> >>> >get it working. > >>> >>> > > >>> >>> >On Thu, 26 Jan 2023 at 14:32, Peter Price ***@***.***> wrote: > >>> >>> > > >>> >>> >> Good luck with that :-) > >>> >>> >> > >>> >>> >> The code has a lot of atmega specific code for the hardware > >>> >>> >interface. > >>> >>> >> Because of the overhead the code doesn't use the Arduino IO > >>> >>functions > >>> >>> >but > >>> >>> >> drives the GPIO pins directly via the registers. > >>> >>> >> > >>> >>> >> TX uses the SPI interface to fill the cc1101 TX fifo, but, > >>> >because > >>> >>of > >>> >>> >the > >>> >>> >> jitter on the incoming signals from the other devices, you > >can't > >>> >>use > >>> >>> >the > >>> >>> >> cc1101 rx fifo to capture the data because it assumes > >everything > >>> >>is > >>> >>> >> synchronous. > >>> >>> >> > >>> >>> >> If you try a port then I suggest you get the SPI interface to > >the > >>> >>> >CC1101 > >>> >>> >> working first and then the HW UART interface between the STM > >and > >>> >>the > >>> >>> >> CC1101. This is just an ISR triggered by the UART that reads > >the > >>> >>UART > >>> >>> >RX > >>> >>> >> data into a buffer. > >>> >>> >> > >>> >>> >> If the STM hasn't got a HW UART available then you'll need to > >be > >>> >>good > >>> >>> >at > >>> >>> >> coding. I suspect the STM8 HW UART has been connected to the > >host > >>> >>> >USB > >>> >>> >> interface so this is going to be the case. > >>> >>> >> > >>> >>> >> The atmega328p SW UART code uses a HW interrupt to capture > >the > >>> >>timing > >>> >>> >of > >>> >>> >> the signal edges and then a SW trap to process the captured > >data > >>> >>> >edges to > >>> >>> >> generate an RX byte. This is very processor heavy and every > >cycle > >>> >>is > >>> >>> >> critical to keep up with the data when it arrives. The SW > >UART > >>> >>won't > >>> >>> >work > >>> >>> >> on an atmega clocked at less than 16MHz because there aren't > >>> >>enough > >>> >>> >> instruction cycles available. > >>> >>> >> > >>> >>> >> The SW UART code is not as good at RXing radio messages as > >the HW > >>> >>> >UART > >>> >>> >> code. > >>> >>> >> > >>> >>> >> Using a simple USB logic analyser ( e.g. > >>> >>> >> > >>> >>> > > >>> >>> > >>> >> > >>> > > > https://www.amazon.co.uk/Hobby-Components-24MHz-Analyser-1-1-16/dp/B00DAYAREW > >>> >>> ) > >>> >>> >> there are some debug lines still in the code that you can use > >to > >>> >>> >drive > >>> >>> >> spare GPIO pins that will show you how much processor time > >you're > >>> >>> >using in > >>> >>> >> the HW and SW ISR functions. > >>> >>> >> > >>> >>> >> The frame, message and host interface code should work > >without > >>> >>> >significant > >>> >>> >> changes. > >>> >>> >> > >>> >>> >> That's all the help I can offer since I have zero STM > >knowledge. > >>> >>> >> > >>> >>> >> If you don't understand what I've said above give up now. > >>> >>> >> > >>> >>> >> — > >>> >>> >> Reply to this email directly, view it on GitHub > >>> >>> >> > >>> >>> > >>> > >>>><#35 (comment) > >, > >>> >>> >or > >>> >>> >> unsubscribe > >>> >>> >> > >>> >>> >< > >>> >>> > >>> >> > >>> > > > https://github.com/notifications/unsubscribe-auth/AN4GHPSSWORQMO6CGL6XQV3WUKDJNANCNFSM6AAAAAAUHJSYXI > >>> >>> > > >>> >>> >> . > >>> >>> >> You are receiving this because you authored the > >thread.Message > >>> >>ID: > >>> >>> >> ***@***.***> > >>> >>> >> > >>> >>> > > >>> >>> > > >>> >>> >-- > >>> >>> >Reply to this email directly or view it on GitHub: > >>> >>> > >>#35 (comment) > >>> >>> >You are receiving this because you commented. > >>> >>> > > >>> >>> >Message ID: ***@***.***> > >>> >>> > >>> >>> — > >>> >>> Reply to this email directly, view it on GitHub > >>> >>> > >>> > >>><#35 (comment)>, > >>> >>or > >>> >>> unsubscribe > >>> >>> > >>> >>< > >>> > > > https://github.com/notifications/unsubscribe-auth/AN4GHPWOTGSC3DO2F7TN4M3WUK6FHANCNFSM6AAAAAAUHJSYXI > >>> > > >>> >>> . > >>> >>> You are receiving this because you authored the thread.Message > >ID: > >>> >>> ***@***.***> > >>> >>> > >>> >> > >>> >> > >>> >>-- > >>> >>Reply to this email directly or view it on GitHub: > >>> > >>>#35 (comment) > >>> >>You are receiving this because you commented. > >>> >> > >>> >>Message ID: ***@***.***> > >>> > >>> — > >>> Reply to this email directly, view it on GitHub > >>> > ><#35 (comment)>, > >>> or unsubscribe > >>> > >< > https://github.com/notifications/unsubscribe-auth/AN4GHPWDEQVBRFCQWOYLZOLWULYNPANCNFSM6AAAAAAUHJSYXI > > > >>> . > >>> You are receiving this because you authored the thread.Message ID: > >>> ***@***.***> > >>> > >> > > > > > >-- > >Reply to this email directly or view it on GitHub: > >#35 (comment) > >You are receiving this because you commented. > > > >Message ID: ***@***.***> > > — > Reply to this email directly, view it on GitHub > <#35 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AN4GHPWNBGQWDHVC25NK6GLWUVN2ZANCNFSM6AAAAAAUHJSYXI> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

On Sun, 29 Jan 2023, 19:42 Peter Price, ***@***.***> wrote: This is the pinout for the Leonardo I’m referring to and the E07 radio module You need to connect the following Leonardo E07 D0/RX 14 D1/TX 15 3V3 9 GND 12 D10/PB6/SS 19 And from the ICSP header (check online for ICSP pinout) MOSI 17 MISO 16 SCK 18 Some of the E07 pins are probably available elsewhere on the dev card. Don’t forget you need to make sure the STM8 doesn’t try to access the E07 at the same time as the Leonardo From: pdbayes ***@***.*** Sent: 29 January 2023 17:16 To: ghoti57/evofw3 ***@***.***> Cc: Peter Price ***@***.***>; Comment ***@***.***> Subject: Re: [ghoti57/evofw3] STM8 (Issue #35) Hi. Got my Leonardo board, serial monitor reports evofw3 0.7.1. Can you let me know the connections please. Thank you On Sat, 28 Jan 2023, 19:18 Paul Bayes, ***@***.*** <mailto:***@***.***> > wrote: > Thanks. I've ordered a Leonardo as I have a prototype shield in this > format, which might help keep things tidy. > > On Sat, 28 Jan 2023, 18:06 Peter Price, ***@***.*** <mailto:***@***.***> > wrote: > >> You want something with an atmega32u4 processor. This will have a direct >> usb interface to the host (no driver required) and leaves the HW UART free >> to connect to the CC1101. >> >> Avoid atmega328 based devices. >> >> When you have it let me know exactly what you have and I'll tell you the >> connections you need. >> >> ⁣Get BlueMail for Android ​ >> >> On 28 Jan 2023, 16:08, at 16:08, pdbayes ***@***.*** <mailto:***@***.***> > wrote: >> >Last question I promise. I have a different recover now with no MCU. >> >Which >> >MCU have you found works best. I have an old cloned Nano but It won't >> >load >> >the sketch. I think it has a Chinese rip off usb chip that's not great >> >and >> >that is causing issues. Would the latest Nano be a good choice. >> > >> >On Fri, 27 Jan 2023, 06:57 Paul Bayes, ***@***.*** <mailto:***@***.***> > wrote: >> > >> >> I have an Uno so should be ok. Thanks for your help >> >> >> >> On Thu, 26 Jan 2023, 22:06 Peter Price, ***@***.*** <mailto:***@***.***> > wrote: >> >> >> >>> Just thought. >> >>> >> >>> The power to the e7 will have to come from the Arduino. >> >>> >> >>> It will also be connected to the STM8 so you need to be sure that >> >it >> >>> doesn't configure it's GOIOs in such a way that it interferes >> >>> >> >>> ⁣Get BlueMail for Android ​ >> >>> >> >>> On 26 Jan 2023, 22:00, at 22:00, Peter Price ***@***.*** <mailto:***@***.***> > wrote: >> >>> >If you have an Arduino with an atmega32u4 or a 16MHz atmega328p and >> >you >> >>> >connect it correctly it will work with no code changes. >> >>> > >> >>> >If you only have an 8MHz atmega328p it won't. >> >>> > >> >>> >⁣Get BlueMail for Android ​ >> >>> > >> >>> >On 26 Jan 2023, 20:00, at 20:00, pdbayes ***@***.*** <mailto:***@***.***> > >> >>> >wrote: >> >>> >>Hmmm. I wonder if I could hard wire the GDO pins from the e07 >> >module >> >>> >to >> >>> >>an >> >>> >>Arduino I have spare? Will depend on what the STM8 is doing on >> >those >> >>> >>pins >> >>> >>or any intermediate components. Or maybe using software on the >> >STM8 >> >>> >>the >> >>> >>recieved data could be sent as is to an io pin. >> >>> >> >> >>> >>On Thu, 26 Jan 2023, 18:22 Peter Price, ***@***.*** <mailto:***@***.***> > wrote: >> >>> >> >> >>> >>> I think you've misunderstood about the UART in the context of >> >>> >>evofw3. >> >>> >>> >> >>> >>> The bitstream that comes out of the cc1101 in an evohome >> >environment >> >>> >>has >> >>> >>> effectively been generated by UARTs in the Evo devices >> >(controller, >> >>> >>rad >> >>> >>> stats, thermostats etc) >> >>> >>> >> >>> >>> This means you need a UART interface in the STM8 facing the >> >CC1101. >> >>> >>> >> >>> >>> On your Dev board the HW UART in the STM8 is almost certainly >> >>> >>connected to >> >>> >>> the USB connector on the board. >> >>> >>> >> >>> >>> This means the connection to GDO0 and GD02 of the CC1101 will >> >be >> >>> >>using two >> >>> >>> ordinary GPIO signals. That means you have to implement a SW >> >UART >> >>> >in >> >>> >>the >> >>> >>> STM8 to decode the bitstream. You have to be able to >> >synchronise >> >>> >>with the >> >>> >>> stop/start bits in the bitstream so that you can identify and >> >>> >extract >> >>> >>the >> >>> >>> real data. >> >>> >>> >> >>> >>> You are not dealing with a synchronous system. It's >> >asynchronous >> >>> >>because >> >>> >>> all the devices have their own clock and they're all slightly >> >>> >>different. >> >>> >>> >> >>> >>> You're dealing with a bit stream at 38400 baud with significant >> >>> >>jitter >> >>> >>> generated by some of the devices you are listening to. >> >>> >>> >> >>> >>> I very much doubt that the example software will get anywhere >> >near >> >>> >>> extracting the data you need. >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> ⁣Get BlueMail for Android ​ >> >>> >>> >> >>> >>> On 26 Jan 2023, 15:04, at 15:04, pdbayes ***@***.*** <mailto:***@***.***> > wrote: >> >>> >>> >Thanks for the advice. >> >>> >>> >The dev board is this: >> >>> >>> >https://www.ebyte.com/en/product-view-news.html?id=1691 >> >>> >>> >All the UART side of things should be handled and I was hoping >> >I >> >>> >>would >> >>> >>> >just >> >>> >>> >have a stream of bits to deal with on the pi/pc. They say it >> >comes >> >>> >>> >with >> >>> >>> >example software to do this but it is within a commercial IDE >> >you >> >>> >>have >> >>> >>> >to >> >>> >>> >pay for. It has a free trial so hopefully that will give me >> >enough >> >>> >>time >> >>> >>> >to >> >>> >>> >get it working. >> >>> >>> > >> >>> >>> >On Thu, 26 Jan 2023 at 14:32, Peter Price ***@***.*** <mailto:***@***.***> > wrote: >> >>> >>> > >> >>> >>> >> Good luck with that :-) >> >>> >>> >> >> >>> >>> >> The code has a lot of atmega specific code for the hardware >> >>> >>> >interface. >> >>> >>> >> Because of the overhead the code doesn't use the Arduino IO >> >>> >>functions >> >>> >>> >but >> >>> >>> >> drives the GPIO pins directly via the registers. >> >>> >>> >> >> >>> >>> >> TX uses the SPI interface to fill the cc1101 TX fifo, but, >> >>> >because >> >>> >>of >> >>> >>> >the >> >>> >>> >> jitter on the incoming signals from the other devices, you >> >can't >> >>> >>use >> >>> >>> >the >> >>> >>> >> cc1101 rx fifo to capture the data because it assumes >> >everything >> >>> >>is >> >>> >>> >> synchronous. >> >>> >>> >> >> >>> >>> >> If you try a port then I suggest you get the SPI interface to >> >the >> >>> >>> >CC1101 >> >>> >>> >> working first and then the HW UART interface between the STM >> >and >> >>> >>the >> >>> >>> >> CC1101. This is just an ISR triggered by the UART that reads >> >the >> >>> >>UART >> >>> >>> >RX >> >>> >>> >> data into a buffer. >> >>> >>> >> >> >>> >>> >> If the STM hasn't got a HW UART available then you'll need to >> >be >> >>> >>good >> >>> >>> >at >> >>> >>> >> coding. I suspect the STM8 HW UART has been connected to the >> >host >> >>> >>> >USB >> >>> >>> >> interface so this is going to be the case. >> >>> >>> >> >> >>> >>> >> The atmega328p SW UART code uses a HW interrupt to capture >> >the >> >>> >>timing >> >>> >>> >of >> >>> >>> >> the signal edges and then a SW trap to process the captured >> >data >> >>> >>> >edges to >> >>> >>> >> generate an RX byte. This is very processor heavy and every >> >cycle >> >>> >>is >> >>> >>> >> critical to keep up with the data when it arrives. The SW >> >UART >> >>> >>won't >> >>> >>> >work >> >>> >>> >> on an atmega clocked at less than 16MHz because there aren't >> >>> >>enough >> >>> >>> >> instruction cycles available. >> >>> >>> >> >> >>> >>> >> The SW UART code is not as good at RXing radio messages as >> >the HW >> >>> >>> >UART >> >>> >>> >> code. >> >>> >>> >> >> >>> >>> >> Using a simple USB logic analyser ( e.g. >> >>> >>> >> >> >>> >>> > >> >>> >>> >> >>> >> >> >>> >> > >> https://www.amazon.co.uk/Hobby-Components-24MHz-Analyser-1-1-16/dp/B00DAYAREW >> >>> >>> ) >> >>> >>> >> there are some debug lines still in the code that you can use >> >to >> >>> >>> >drive >> >>> >>> >> spare GPIO pins that will show you how much processor time >> >you're >> >>> >>> >using in >> >>> >>> >> the HW and SW ISR functions. >> >>> >>> >> >> >>> >>> >> The frame, message and host interface code should work >> >without >> >>> >>> >significant >> >>> >>> >> changes. >> >>> >>> >> >> >>> >>> >> That's all the help I can offer since I have zero STM >> >knowledge. >> >>> >>> >> >> >>> >>> >> If you don't understand what I've said above give up now. >> >>> >>> >> >> >>> >>> >> — >> >>> >>> >> Reply to this email directly, view it on GitHub >> >>> >>> >> >> >>> >>> >> >>> >> >>>>< #35 (comment) < #35 (comment) > >> >, >> >>> >>> >or >> >>> >>> >> unsubscribe >> >>> >>> >> >> >>> >>> >< >> >>> >>> >> >>> >> >> >>> >> > >> https://github.com/notifications/unsubscribe-auth/AN4GHPSSWORQMO6CGL6XQV3WUKDJNANCNFSM6AAAAAAUHJSYXI >> >>> >>> > >> >>> >>> >> . >> >>> >>> >> You are receiving this because you authored the >> >thread.Message >> >>> >>ID: >> >>> >>> >> ***@***.*** <mailto:***@***.***> > >> >>> >>> >> >> >>> >>> > >> >>> >>> > >> >>> >>> >-- >> >>> >>> >Reply to this email directly or view it on GitHub: >> >>> >>> >> >>#35 (comment) >> >>> >>> >You are receiving this because you commented. >> >>> >>> > >> >>> >>> >Message ID: ***@***.*** <mailto:***@***.***> > >> >>> >>> >> >>> >>> — >> >>> >>> Reply to this email directly, view it on GitHub >> >>> >>> >> >>> >> >>><#35 (comment) >, >> >>> >>or >> >>> >>> unsubscribe >> >>> >>> >> >>> >>< >> >>> >> > >> https://github.com/notifications/unsubscribe-auth/AN4GHPWOTGSC3DO2F7TN4M3WUK6FHANCNFSM6AAAAAAUHJSYXI >> >>> > >> >>> >>> . >> >>> >>> You are receiving this because you authored the thread.Message >> >ID: >> >>> >>> ***@***.*** <mailto:***@***.***> > >> >>> >>> >> >>> >> >> >>> >> >> >>> >>-- >> >>> >>Reply to this email directly or view it on GitHub: >> >>> >> >>>#35 (comment) >> >>> >>You are receiving this because you commented. >> >>> >> >> >>> >>Message ID: ***@***.*** <mailto:***@***.***> > >> >>> >> >>> — >> >>> Reply to this email directly, view it on GitHub >> >>> >> ><#35 (comment)>, >> >>> or unsubscribe >> >>> >> >< >> https://github.com/notifications/unsubscribe-auth/AN4GHPWDEQVBRFCQWOYLZOLWULYNPANCNFSM6AAAAAAUHJSYXI >> > >> >>> . >> >>> You are receiving this because you authored the thread.Message ID: >> >>> ***@***.*** <mailto:***@***.***> > >> >>> >> >> >> > >> > >> >-- >> >Reply to this email directly or view it on GitHub: >> >#35 (comment) >> >You are receiving this because you commented. >> > >> >Message ID: ***@***.*** <mailto:***@***.***> > >> >> — >> Reply to this email directly, view it on GitHub >> <#35 (comment)>, >> or unsubscribe >> < https://github.com/notifications/unsubscribe-auth/AN4GHPWNBGQWDHVC25NK6GLWUVN2ZANCNFSM6AAAAAAUHJSYXI > >> . >> You are receiving this because you authored the thread.Message ID: >> ***@***.*** <mailto:***@***.***> > >> > — Reply to this email directly, view it on GitHub < #35 (comment)> , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AIRU2WZ6QZ2JTH4S7JDX2OLWU2QWFANCNFSM6AAAAAAUHJSYXI> . You are receiving this because you commented. < https://github.com/notifications/beacon/AIRU2W6ZSCHUD2NWHFVREOTWU2QWFA5CNFSM6AAAAAAUHJSYXKWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTST5ANTO.gif> Message ID: < ***@***.***> ***@***.***> — Reply to this email directly, view it on GitHub <#35 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AN4GHPWVQWX2H6DMZ7ZWXZTWU3B2XANCNFSM6AAAAAAUHJSYXI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

On Tue, 31 Jan 2023, 22:26 Peter Price, ***@***.***> wrote: While the cc1101 will operate in all those frequency bands the circuit between the chip and antenna is different. It's possible that the module you've bought is configured for 433 MHz. It's very unlikely that you can buy a module that will work at all frequencies. You should be able to tell by looking closely at the layout of the components and comparing it to the TI documentation for the CC1101. ⁣Get BlueMail for Android ​ On 31 Jan 2023, 21:04, at 21:04, pdbayes ***@***.***> wrote: >Hi > >I assume if wired correctly and firmware loaded, I should see some data >in >the serial monitor? >I got one of these in the end and cross referenced your connection >instruction with the E07. > https://www.ebay.co.uk/itm/394035907922?mkcid=16&mkevt=1&mkrid=711-127632-2357-0&ssspo=meql5djjqne&sssrc=2349624&ssuid=b_r4gulfrre&var=&widget_ver=artemis&media=COPY > >Currently I only get the firmware version in the monitor. > >On Sun, 29 Jan 2023, 21:16 Paul Bayes, ***@***.***> wrote: > >> Thanks for your help. I'll give it a go later this week. >> >> On Sun, 29 Jan 2023, 19:42 Peter Price, ***@***.***> wrote: >> >>> This is the pinout for the Leonardo I’m referring to and the E07 >radio >>> module >>> >>> >>> >>> >>> >>> You need to connect the following >>> >>> >>> >>> Leonardo E07 >>> >>> D0/RX 14 >>> >>> D1/TX 15 >>> >>> 3V3 9 >>> >>> GND 12 >>> >>> D10/PB6/SS 19 >>> >>> >>> >>> And from the ICSP header (check online for ICSP pinout) >>> >>> MOSI 17 >>> >>> MISO 16 >>> >>> SCK 18 >>> >>> >>> >>> Some of the E07 pins are probably available elsewhere on the dev >card. >>> >>> >>> >>> Don’t forget you need to make sure the STM8 doesn’t try to access >the E07 >>> at the same time as the Leonardo >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> From: pdbayes ***@***.*** >>> Sent: 29 January 2023 17:16 >>> To: ghoti57/evofw3 ***@***.***> >>> Cc: Peter Price ***@***.***>; Comment ***@***.***> >>> Subject: Re: [ghoti57/evofw3] STM8 (Issue #35) >>> >>> >>> >>> Hi. Got my Leonardo board, serial monitor reports evofw3 0.7.1. >>> Can you let me know the connections please. >>> Thank you >>> >>> >>> >>> On Sat, 28 Jan 2023, 19:18 Paul Bayes, ***@***.*** ><mailto:***@***.***> >>> > wrote: >>> >>> > Thanks. I've ordered a Leonardo as I have a prototype shield in >this >>> > format, which might help keep things tidy. >>> > >>> > On Sat, 28 Jan 2023, 18:06 Peter Price, ***@***.*** ><mailto:***@***.***> >>> > wrote: >>> > >>> >> You want something with an atmega32u4 processor. This will have >a >>> direct >>> >> usb interface to the host (no driver required) and leaves the HW >UART >>> free >>> >> to connect to the CC1101. >>> >> >>> >> Avoid atmega328 based devices. >>> >> >>> >> When you have it let me know exactly what you have and I'll tell >you >>> the >>> >> connections you need. >>> >> >>> >> ⁣Get BlueMail for Android ​ >>> >> >>> >> On 28 Jan 2023, 16:08, at 16:08, pdbayes ***@***.*** ><mailto:***@***.***> >>> > wrote: >>> >> >Last question I promise. I have a different recover now with no >MCU. >>> >> >Which >>> >> >MCU have you found works best. I have an old cloned Nano but It >won't >>> >> >load >>> >> >the sketch. I think it has a Chinese rip off usb chip that's not >great >>> >> >and >>> >> >that is causing issues. Would the latest Nano be a good choice. >>> >> > >>> >> >On Fri, 27 Jan 2023, 06:57 Paul Bayes, ***@***.*** ><mailto:***@***.***> >>> > wrote: >>> >> > >>> >> >> I have an Uno so should be ok. Thanks for your help >>> >> >> >>> >> >> On Thu, 26 Jan 2023, 22:06 Peter Price, ***@***.*** ><mailto:***@***.***> >>> > wrote: >>> >> >> >>> >> >>> Just thought. >>> >> >>> >>> >> >>> The power to the e7 will have to come from the Arduino. >>> >> >>> >>> >> >>> It will also be connected to the STM8 so you need to be sure >that >>> >> >it >>> >> >>> doesn't configure it's GOIOs in such a way that it >interferes >>> >> >>> >>> >> >>> ⁣Get BlueMail for Android ​ >>> >> >>> >>> >> >>> On 26 Jan 2023, 22:00, at 22:00, Peter Price ***@***.*** ><mailto:***@***.***> >>> > wrote: >>> >> >>> >If you have an Arduino with an atmega32u4 or a 16MHz >atmega328p >>> and >>> >> >you >>> >> >>> >connect it correctly it will work with no code changes. >>> >> >>> > >>> >> >>> >If you only have an 8MHz atmega328p it won't. >>> >> >>> > >>> >> >>> >⁣Get BlueMail for Android ​ >>> >> >>> > >>> >> >>> >On 26 Jan 2023, 20:00, at 20:00, pdbayes ***@***.*** ><mailto:***@***.***> >>> > >>> >> >>> >wrote: >>> >> >>> >>Hmmm. I wonder if I could hard wire the GDO pins from the >e07 >>> >> >module >>> >> >>> >to >>> >> >>> >>an >>> >> >>> >>Arduino I have spare? Will depend on what the STM8 is doing >on >>> >> >those >>> >> >>> >>pins >>> >> >>> >>or any intermediate components. Or maybe using software on >the >>> >> >STM8 >>> >> >>> >>the >>> >> >>> >>recieved data could be sent as is to an io pin. >>> >> >>> >> >>> >> >>> >>On Thu, 26 Jan 2023, 18:22 Peter Price, ***@***.*** ><mailto:***@***.***> >>> > wrote: >>> >> >>> >> >>> >> >>> >>> I think you've misunderstood about the UART in the >context of >>> >> >>> >>evofw3. >>> >> >>> >>> >>> >> >>> >>> The bitstream that comes out of the cc1101 in an evohome >>> >> >environment >>> >> >>> >>has >>> >> >>> >>> effectively been generated by UARTs in the Evo devices >>> >> >(controller, >>> >> >>> >>rad >>> >> >>> >>> stats, thermostats etc) >>> >> >>> >>> >>> >> >>> >>> This means you need a UART interface in the STM8 facing >the >>> >> >CC1101. >>> >> >>> >>> >>> >> >>> >>> On your Dev board the HW UART in the STM8 is almost >certainly >>> >> >>> >>connected to >>> >> >>> >>> the USB connector on the board. >>> >> >>> >>> >>> >> >>> >>> This means the connection to GDO0 and GD02 of the CC1101 >will >>> >> >be >>> >> >>> >>using two >>> >> >>> >>> ordinary GPIO signals. That means you have to implement a >SW >>> >> >UART >>> >> >>> >in >>> >> >>> >>the >>> >> >>> >>> STM8 to decode the bitstream. You have to be able to >>> >> >synchronise >>> >> >>> >>with the >>> >> >>> >>> stop/start bits in the bitstream so that you can identify >and >>> >> >>> >extract >>> >> >>> >>the >>> >> >>> >>> real data. >>> >> >>> >>> >>> >> >>> >>> You are not dealing with a synchronous system. It's >>> >> >asynchronous >>> >> >>> >>because >>> >> >>> >>> all the devices have their own clock and they're all >slightly >>> >> >>> >>different. >>> >> >>> >>> >>> >> >>> >>> You're dealing with a bit stream at 38400 baud with >significant >>> >> >>> >>jitter >>> >> >>> >>> generated by some of the devices you are listening to. >>> >> >>> >>> >>> >> >>> >>> I very much doubt that the example software will get >anywhere >>> >> >near >>> >> >>> >>> extracting the data you need. >>> >> >>> >>> >>> >> >>> >>> >>> >> >>> >>> >>> >> >>> >>> ⁣Get BlueMail for Android ​ >>> >> >>> >>> >>> >> >>> >>> On 26 Jan 2023, 15:04, at 15:04, pdbayes ***@***.*** ><mailto:***@***.***> >>> > wrote: >>> >> >>> >>> >Thanks for the advice. >>> >> >>> >>> >The dev board is this: >>> >> >>> >>> >https://www.ebyte.com/en/product-view-news.html?id=1691 >>> >> >>> >>> >All the UART side of things should be handled and I was >hoping >>> >> >I >>> >> >>> >>would >>> >> >>> >>> >just >>> >> >>> >>> >have a stream of bits to deal with on the pi/pc. They >say it >>> >> >comes >>> >> >>> >>> >with >>> >> >>> >>> >example software to do this but it is within a >commercial IDE >>> >> >you >>> >> >>> >>have >>> >> >>> >>> >to >>> >> >>> >>> >pay for. It has a free trial so hopefully that will give >me >>> >> >enough >>> >> >>> >>time >>> >> >>> >>> >to >>> >> >>> >>> >get it working. >>> >> >>> >>> > >>> >> >>> >>> >On Thu, 26 Jan 2023 at 14:32, Peter Price ***@***.*** ><mailto:***@***.***> >>> > wrote: >>> >> >>> >>> > >>> >> >>> >>> >> Good luck with that :-) >>> >> >>> >>> >> >>> >> >>> >>> >> The code has a lot of atmega specific code for the >hardware >>> >> >>> >>> >interface. >>> >> >>> >>> >> Because of the overhead the code doesn't use the >Arduino IO >>> >> >>> >>functions >>> >> >>> >>> >but >>> >> >>> >>> >> drives the GPIO pins directly via the registers. >>> >> >>> >>> >> >>> >> >>> >>> >> TX uses the SPI interface to fill the cc1101 TX fifo, >but, >>> >> >>> >because >>> >> >>> >>of >>> >> >>> >>> >the >>> >> >>> >>> >> jitter on the incoming signals from the other devices, >you >>> >> >can't >>> >> >>> >>use >>> >> >>> >>> >the >>> >> >>> >>> >> cc1101 rx fifo to capture the data because it assumes >>> >> >everything >>> >> >>> >>is >>> >> >>> >>> >> synchronous. >>> >> >>> >>> >> >>> >> >>> >>> >> If you try a port then I suggest you get the SPI >interface >>> to >>> >> >the >>> >> >>> >>> >CC1101 >>> >> >>> >>> >> working first and then the HW UART interface between >the STM >>> >> >and >>> >> >>> >>the >>> >> >>> >>> >> CC1101. This is just an ISR triggered by the UART that >reads >>> >> >the >>> >> >>> >>UART >>> >> >>> >>> >RX >>> >> >>> >>> >> data into a buffer. >>> >> >>> >>> >> >>> >> >>> >>> >> If the STM hasn't got a HW UART available then you'll >need >>> to >>> >> >be >>> >> >>> >>good >>> >> >>> >>> >at >>> >> >>> >>> >> coding. I suspect the STM8 HW UART has been connected >to the >>> >> >host >>> >> >>> >>> >USB >>> >> >>> >>> >> interface so this is going to be the case. >>> >> >>> >>> >> >>> >> >>> >>> >> The atmega328p SW UART code uses a HW interrupt to >capture >>> >> >the >>> >> >>> >>timing >>> >> >>> >>> >of >>> >> >>> >>> >> the signal edges and then a SW trap to process the >captured >>> >> >data >>> >> >>> >>> >edges to >>> >> >>> >>> >> generate an RX byte. This is very processor heavy and >every >>> >> >cycle >>> >> >>> >>is >>> >> >>> >>> >> critical to keep up with the data when it arrives. The >SW >>> >> >UART >>> >> >>> >>won't >>> >> >>> >>> >work >>> >> >>> >>> >> on an atmega clocked at less than 16MHz because there >aren't >>> >> >>> >>enough >>> >> >>> >>> >> instruction cycles available. >>> >> >>> >>> >> >>> >> >>> >>> >> The SW UART code is not as good at RXing radio >messages as >>> >> >the HW >>> >> >>> >>> >UART >>> >> >>> >>> >> code. >>> >> >>> >>> >> >>> >> >>> >>> >> Using a simple USB logic analyser ( e.g. >>> >> >>> >>> >> >>> >> >>> >>> > >>> >> >>> >>> >>> >> >>> >> >>> >> >>> >>> >> > >>> >> >>> > https://www.amazon.co.uk/Hobby-Components-24MHz-Analyser-1-1-16/dp/B00DAYAREW >>> >> >>> >>> ) >>> >> >>> >>> >> there are some debug lines still in the code that you >can >>> use >>> >> >to >>> >> >>> >>> >drive >>> >> >>> >>> >> spare GPIO pins that will show you how much processor >time >>> >> >you're >>> >> >>> >>> >using in >>> >> >>> >>> >> the HW and SW ISR functions. >>> >> >>> >>> >> >>> >> >>> >>> >> The frame, message and host interface code should >work >>> >> >without >>> >> >>> >>> >significant >>> >> >>> >>> >> changes. >>> >> >>> >>> >> >>> >> >>> >>> >> That's all the help I can offer since I have zero STM >>> >> >knowledge. >>> >> >>> >>> >> >>> >> >>> >>> >> If you don't understand what I've said above give up >now. >>> >> >>> >>> >> >>> >> >>> >>> >> — >>> >> >>> >>> >> Reply to this email directly, view it on GitHub >>> >> >>> >>> >> >>> >> >>> >>> >>> >> >>> >>> >> >>>>< >>> #35 (comment) >< >>> #35 (comment) >> >>> >> >, >>> >> >>> >>> >or >>> >> >>> >>> >> unsubscribe >>> >> >>> >>> >> >>> >> >>> >>> >< >>> >> >>> >>> >>> >> >>> >> >>> >> >>> >>> >> > >>> >> >>> > https://github.com/notifications/unsubscribe-auth/AN4GHPSSWORQMO6CGL6XQV3WUKDJNANCNFSM6AAAAAAUHJSYXI >>> >> >>> >>> > >>> >> >>> >>> >> . >>> >> >>> >>> >> You are receiving this because you authored the >>> >> >thread.Message >>> >> >>> >>ID: >>> >> >>> >>> >> ***@***.*** <mailto:***@***.***> > >>> >> >>> >>> >> >>> >> >>> >>> > >>> >> >>> >>> > >>> >> >>> >>> >-- >>> >> >>> >>> >Reply to this email directly or view it on GitHub: >>> >> >>> >>> >>> >> >>>#35 (comment) >>> >> >>> >>> >You are receiving this because you commented. >>> >> >>> >>> > >>> >> >>> >>> >Message ID: ***@***.*** <mailto:***@***.***> > >>> >> >>> >>> >>> >> >>> >>> — >>> >> >>> >>> Reply to this email directly, view it on GitHub >>> >> >>> >>> >>> >> >>> >>> >> >>>< >>> >#35 (comment)>, >>> >> >>> >>or >>> >> >>> >>> unsubscribe >>> >> >>> >>> >>> >> >>> >>< >>> >> >>> >>> >> > >>> >> >>> > https://github.com/notifications/unsubscribe-auth/AN4GHPWOTGSC3DO2F7TN4M3WUK6FHANCNFSM6AAAAAAUHJSYXI >>> >> >>> > >>> >> >>> >>> . >>> >> >>> >>> You are receiving this because you authored the >thread.Message >>> >> >ID: >>> >> >>> >>> ***@***.*** <mailto:***@***.***> > >>> >> >>> >>> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >>-- >>> >> >>> >>Reply to this email directly or view it on GitHub: >>> >> >>> >>> >> >>>>#35 (comment) >>> >> >>> >>You are receiving this because you commented. >>> >> >>> >> >>> >> >>> >>Message ID: ***@***.*** <mailto:***@***.***> > >>> >> >>> >>> >> >>> — >>> >> >>> Reply to this email directly, view it on GitHub >>> >> >>> >>> >> >><#35 (comment) >>> >, >>> >> >>> or unsubscribe >>> >> >>> >>> >> >< >>> >> >>> > https://github.com/notifications/unsubscribe-auth/AN4GHPWDEQVBRFCQWOYLZOLWULYNPANCNFSM6AAAAAAUHJSYXI >>> >> > >>> >> >>> . >>> >> >>> You are receiving this because you authored the >thread.Message ID: >>> >> >>> ***@***.*** <mailto:***@***.***> > >>> >> >>> >>> >> >> >>> >> > >>> >> > >>> >> >-- >>> >> >Reply to this email directly or view it on GitHub: >>> >> >>#35 (comment) >>> >> >You are receiving this because you commented. >>> >> > >>> >> >Message ID: ***@***.*** <mailto:***@***.***> > >>> >> >>> >> — >>> >> Reply to this email directly, view it on GitHub >>> >> ><#35 (comment)>, >>> >> or unsubscribe >>> >> < >>> > https://github.com/notifications/unsubscribe-auth/AN4GHPWNBGQWDHVC25NK6GLWUVN2ZANCNFSM6AAAAAAUHJSYXI >>> > >>> >> . >>> >> You are receiving this because you authored the thread.Message >ID: >>> >> ***@***.*** <mailto:***@***.***> > >>> >> >>> > >>> >>> >>> >>> — >>> Reply to this email directly, view it on GitHub < >>> #35 (comment)> >, >>> or unsubscribe < >>> > https://github.com/notifications/unsubscribe-auth/AIRU2WZ6QZ2JTH4S7JDX2OLWU2QWFANCNFSM6AAAAAAUHJSYXI > >>> . >>> You are receiving this because you commented. < >>> > https://github.com/notifications/beacon/AIRU2W6ZSCHUD2NWHFVREOTWU2QWFA5CNFSM6AAAAAAUHJSYXKWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTST5ANTO.gif > >>> Message ID: < ***@***.***> ***@***.***> >>> >>> — >>> Reply to this email directly, view it on GitHub >>> ><#35 (comment)>, >>> or unsubscribe >>> >< https://github.com/notifications/unsubscribe-auth/AN4GHPWVQWX2H6DMZ7ZWXZTWU3B2XANCNFSM6AAAAAAUHJSYXI > >>> . >>> You are receiving this because you authored the thread.Message ID: >>> ***@***.***> >>> >> > > >-- >Reply to this email directly or view it on GitHub: >#35 (comment) >You are receiving this because you commented. > >Message ID: ***@***.***> — Reply to this email directly, view it on GitHub <#35 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AN4GHPQ66E3C37NVCBNLY4LWVGGSVANCNFSM6AAAAAAUHJSYXI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

On Tue, 31 Jan 2023, 22:48 Paul Bayes, ***@***.***> wrote: That's a good point. It doesn't say which of the frequencies it's configured for. I'll mail him. Pain in the bum. On Tue, 31 Jan 2023, 22:26 Peter Price, ***@***.***> wrote: > While the cc1101 will operate in all those frequency bands the circuit > between the chip and antenna is different. > > It's possible that the module you've bought is configured for 433 MHz. > It's very unlikely that you can buy a module that will work at all > frequencies. > > You should be able to tell by looking closely at the layout of the > components and comparing it to the TI documentation for the CC1101. > > ⁣Get BlueMail for Android ​ > > On 31 Jan 2023, 21:04, at 21:04, pdbayes ***@***.***> wrote: > >Hi > > > >I assume if wired correctly and firmware loaded, I should see some data > >in > >the serial monitor? > >I got one of these in the end and cross referenced your connection > >instruction with the E07. > > > https://www.ebay.co.uk/itm/394035907922?mkcid=16&mkevt=1&mkrid=711-127632-2357-0&ssspo=meql5djjqne&sssrc=2349624&ssuid=b_r4gulfrre&var=&widget_ver=artemis&media=COPY > > > >Currently I only get the firmware version in the monitor. > > > >On Sun, 29 Jan 2023, 21:16 Paul Bayes, ***@***.***> wrote: > > > >> Thanks for your help. I'll give it a go later this week. > >> > >> On Sun, 29 Jan 2023, 19:42 Peter Price, ***@***.***> wrote: > >> > >>> This is the pinout for the Leonardo I’m referring to and the E07 > >radio > >>> module > >>> > >>> > >>> > >>> > >>> > >>> You need to connect the following > >>> > >>> > >>> > >>> Leonardo E07 > >>> > >>> D0/RX 14 > >>> > >>> D1/TX 15 > >>> > >>> 3V3 9 > >>> > >>> GND 12 > >>> > >>> D10/PB6/SS 19 > >>> > >>> > >>> > >>> And from the ICSP header (check online for ICSP pinout) > >>> > >>> MOSI 17 > >>> > >>> MISO 16 > >>> > >>> SCK 18 > >>> > >>> > >>> > >>> Some of the E07 pins are probably available elsewhere on the dev > >card. > >>> > >>> > >>> > >>> Don’t forget you need to make sure the STM8 doesn’t try to access > >the E07 > >>> at the same time as the Leonardo > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> From: pdbayes ***@***.*** > >>> Sent: 29 January 2023 17:16 > >>> To: ghoti57/evofw3 ***@***.***> > >>> Cc: Peter Price ***@***.***>; Comment ***@***.***> > >>> Subject: Re: [ghoti57/evofw3] STM8 (Issue #35) > >>> > >>> > >>> > >>> Hi. Got my Leonardo board, serial monitor reports evofw3 0.7.1. > >>> Can you let me know the connections please. > >>> Thank you > >>> > >>> > >>> > >>> On Sat, 28 Jan 2023, 19:18 Paul Bayes, ***@***.*** > ><mailto:***@***.***> > >>> > wrote: > >>> > >>> > Thanks. I've ordered a Leonardo as I have a prototype shield in > >this > >>> > format, which might help keep things tidy. > >>> > > >>> > On Sat, 28 Jan 2023, 18:06 Peter Price, ***@***.*** > ><mailto:***@***.***> > >>> > wrote: > >>> > > >>> >> You want something with an atmega32u4 processor. This will have > >a > >>> direct > >>> >> usb interface to the host (no driver required) and leaves the HW > >UART > >>> free > >>> >> to connect to the CC1101. > >>> >> > >>> >> Avoid atmega328 based devices. > >>> >> > >>> >> When you have it let me know exactly what you have and I'll tell > >you > >>> the > >>> >> connections you need. > >>> >> > >>> >> ⁣Get BlueMail for Android ​ > >>> >> > >>> >> On 28 Jan 2023, 16:08, at 16:08, pdbayes ***@***.*** > ><mailto:***@***.***> > >>> > wrote: > >>> >> >Last question I promise. I have a different recover now with no > >MCU. > >>> >> >Which > >>> >> >MCU have you found works best. I have an old cloned Nano but It > >won't > >>> >> >load > >>> >> >the sketch. I think it has a Chinese rip off usb chip that's not > >great > >>> >> >and > >>> >> >that is causing issues. Would the latest Nano be a good choice. > >>> >> > > >>> >> >On Fri, 27 Jan 2023, 06:57 Paul Bayes, ***@***.*** > ><mailto:***@***.***> > >>> > wrote: > >>> >> > > >>> >> >> I have an Uno so should be ok. Thanks for your help > >>> >> >> > >>> >> >> On Thu, 26 Jan 2023, 22:06 Peter Price, ***@***.*** > ><mailto:***@***.***> > >>> > wrote: > >>> >> >> > >>> >> >>> Just thought. > >>> >> >>> > >>> >> >>> The power to the e7 will have to come from the Arduino. > >>> >> >>> > >>> >> >>> It will also be connected to the STM8 so you need to be sure > >that > >>> >> >it > >>> >> >>> doesn't configure it's GOIOs in such a way that it > >interferes > >>> >> >>> > >>> >> >>> ⁣Get BlueMail for Android ​ > >>> >> >>> > >>> >> >>> On 26 Jan 2023, 22:00, at 22:00, Peter Price ***@***.*** > ><mailto:***@***.***> > >>> > wrote: > >>> >> >>> >If you have an Arduino with an atmega32u4 or a 16MHz > >atmega328p > >>> and > >>> >> >you > >>> >> >>> >connect it correctly it will work with no code changes. > >>> >> >>> > > >>> >> >>> >If you only have an 8MHz atmega328p it won't. > >>> >> >>> > > >>> >> >>> >⁣Get BlueMail for Android ​ > >>> >> >>> > > >>> >> >>> >On 26 Jan 2023, 20:00, at 20:00, pdbayes ***@***.*** > ><mailto:***@***.***> > >>> > > >>> >> >>> >wrote: > >>> >> >>> >>Hmmm. I wonder if I could hard wire the GDO pins from the > >e07 > >>> >> >module > >>> >> >>> >to > >>> >> >>> >>an > >>> >> >>> >>Arduino I have spare? Will depend on what the STM8 is doing > >on > >>> >> >those > >>> >> >>> >>pins > >>> >> >>> >>or any intermediate components. Or maybe using software on > >the > >>> >> >STM8 > >>> >> >>> >>the > >>> >> >>> >>recieved data could be sent as is to an io pin. > >>> >> >>> >> > >>> >> >>> >>On Thu, 26 Jan 2023, 18:22 Peter Price, ***@***.*** > ><mailto:***@***.***> > >>> > wrote: > >>> >> >>> >> > >>> >> >>> >>> I think you've misunderstood about the UART in the > >context of > >>> >> >>> >>evofw3. > >>> >> >>> >>> > >>> >> >>> >>> The bitstream that comes out of the cc1101 in an evohome > >>> >> >environment > >>> >> >>> >>has > >>> >> >>> >>> effectively been generated by UARTs in the Evo devices > >>> >> >(controller, > >>> >> >>> >>rad > >>> >> >>> >>> stats, thermostats etc) > >>> >> >>> >>> > >>> >> >>> >>> This means you need a UART interface in the STM8 facing > >the > >>> >> >CC1101. > >>> >> >>> >>> > >>> >> >>> >>> On your Dev board the HW UART in the STM8 is almost > >certainly > >>> >> >>> >>connected to > >>> >> >>> >>> the USB connector on the board. > >>> >> >>> >>> > >>> >> >>> >>> This means the connection to GDO0 and GD02 of the CC1101 > >will > >>> >> >be > >>> >> >>> >>using two > >>> >> >>> >>> ordinary GPIO signals. That means you have to implement a > >SW > >>> >> >UART > >>> >> >>> >in > >>> >> >>> >>the > >>> >> >>> >>> STM8 to decode the bitstream. You have to be able to > >>> >> >synchronise > >>> >> >>> >>with the > >>> >> >>> >>> stop/start bits in the bitstream so that you can identify > >and > >>> >> >>> >extract > >>> >> >>> >>the > >>> >> >>> >>> real data. > >>> >> >>> >>> > >>> >> >>> >>> You are not dealing with a synchronous system. It's > >>> >> >asynchronous > >>> >> >>> >>because > >>> >> >>> >>> all the devices have their own clock and they're all > >slightly > >>> >> >>> >>different. > >>> >> >>> >>> > >>> >> >>> >>> You're dealing with a bit stream at 38400 baud with > >significant > >>> >> >>> >>jitter > >>> >> >>> >>> generated by some of the devices you are listening to. > >>> >> >>> >>> > >>> >> >>> >>> I very much doubt that the example software will get > >anywhere > >>> >> >near > >>> >> >>> >>> extracting the data you need. > >>> >> >>> >>> > >>> >> >>> >>> > >>> >> >>> >>> > >>> >> >>> >>> ⁣Get BlueMail for Android ​ > >>> >> >>> >>> > >>> >> >>> >>> On 26 Jan 2023, 15:04, at 15:04, pdbayes ***@***.*** > ><mailto:***@***.***> > >>> > wrote: > >>> >> >>> >>> >Thanks for the advice. > >>> >> >>> >>> >The dev board is this: > >>> >> >>> >>> >https://www.ebyte.com/en/product-view-news.html?id=1691 > >>> >> >>> >>> >All the UART side of things should be handled and I was > >hoping > >>> >> >I > >>> >> >>> >>would > >>> >> >>> >>> >just > >>> >> >>> >>> >have a stream of bits to deal with on the pi/pc. They > >say it > >>> >> >comes > >>> >> >>> >>> >with > >>> >> >>> >>> >example software to do this but it is within a > >commercial IDE > >>> >> >you > >>> >> >>> >>have > >>> >> >>> >>> >to > >>> >> >>> >>> >pay for. It has a free trial so hopefully that will give > >me > >>> >> >enough > >>> >> >>> >>time > >>> >> >>> >>> >to > >>> >> >>> >>> >get it working. > >>> >> >>> >>> > > >>> >> >>> >>> >On Thu, 26 Jan 2023 at 14:32, Peter Price ***@***.*** > ><mailto:***@***.***> > >>> > wrote: > >>> >> >>> >>> > > >>> >> >>> >>> >> Good luck with that :-) > >>> >> >>> >>> >> > >>> >> >>> >>> >> The code has a lot of atmega specific code for the > >hardware > >>> >> >>> >>> >interface. > >>> >> >>> >>> >> Because of the overhead the code doesn't use the > >Arduino IO > >>> >> >>> >>functions > >>> >> >>> >>> >but > >>> >> >>> >>> >> drives the GPIO pins directly via the registers. > >>> >> >>> >>> >> > >>> >> >>> >>> >> TX uses the SPI interface to fill the cc1101 TX fifo, > >but, > >>> >> >>> >because > >>> >> >>> >>of > >>> >> >>> >>> >the > >>> >> >>> >>> >> jitter on the incoming signals from the other devices, > >you > >>> >> >can't > >>> >> >>> >>use > >>> >> >>> >>> >the > >>> >> >>> >>> >> cc1101 rx fifo to capture the data because it assumes > >>> >> >everything > >>> >> >>> >>is > >>> >> >>> >>> >> synchronous. > >>> >> >>> >>> >> > >>> >> >>> >>> >> If you try a port then I suggest you get the SPI > >interface > >>> to > >>> >> >the > >>> >> >>> >>> >CC1101 > >>> >> >>> >>> >> working first and then the HW UART interface between > >the STM > >>> >> >and > >>> >> >>> >>the > >>> >> >>> >>> >> CC1101. This is just an ISR triggered by the UART that > >reads > >>> >> >the > >>> >> >>> >>UART > >>> >> >>> >>> >RX > >>> >> >>> >>> >> data into a buffer. > >>> >> >>> >>> >> > >>> >> >>> >>> >> If the STM hasn't got a HW UART available then you'll > >need > >>> to > >>> >> >be > >>> >> >>> >>good > >>> >> >>> >>> >at > >>> >> >>> >>> >> coding. I suspect the STM8 HW UART has been connected > >to the > >>> >> >host > >>> >> >>> >>> >USB > >>> >> >>> >>> >> interface so this is going to be the case. > >>> >> >>> >>> >> > >>> >> >>> >>> >> The atmega328p SW UART code uses a HW interrupt to > >capture > >>> >> >the > >>> >> >>> >>timing > >>> >> >>> >>> >of > >>> >> >>> >>> >> the signal edges and then a SW trap to process the > >captured > >>> >> >data > >>> >> >>> >>> >edges to > >>> >> >>> >>> >> generate an RX byte. This is very processor heavy and > >every > >>> >> >cycle > >>> >> >>> >>is > >>> >> >>> >>> >> critical to keep up with the data when it arrives. The > >SW > >>> >> >UART > >>> >> >>> >>won't > >>> >> >>> >>> >work > >>> >> >>> >>> >> on an atmega clocked at less than 16MHz because there > >aren't > >>> >> >>> >>enough > >>> >> >>> >>> >> instruction cycles available. > >>> >> >>> >>> >> > >>> >> >>> >>> >> The SW UART code is not as good at RXing radio > >messages as > >>> >> >the HW > >>> >> >>> >>> >UART > >>> >> >>> >>> >> code. > >>> >> >>> >>> >> > >>> >> >>> >>> >> Using a simple USB logic analyser ( e.g. > >>> >> >>> >>> >> > >>> >> >>> >>> > > >>> >> >>> >>> > >>> >> >>> >> > >>> >> >>> > >>> >> > > >>> >> > >>> > > > https://www.amazon.co.uk/Hobby-Components-24MHz-Analyser-1-1-16/dp/B00DAYAREW > >>> >> >>> >>> ) > >>> >> >>> >>> >> there are some debug lines still in the code that you > >can > >>> use > >>> >> >to > >>> >> >>> >>> >drive > >>> >> >>> >>> >> spare GPIO pins that will show you how much processor > >time > >>> >> >you're > >>> >> >>> >>> >using in > >>> >> >>> >>> >> the HW and SW ISR functions. > >>> >> >>> >>> >> > >>> >> >>> >>> >> The frame, message and host interface code should > >work > >>> >> >without > >>> >> >>> >>> >significant > >>> >> >>> >>> >> changes. > >>> >> >>> >>> >> > >>> >> >>> >>> >> That's all the help I can offer since I have zero STM > >>> >> >knowledge. > >>> >> >>> >>> >> > >>> >> >>> >>> >> If you don't understand what I've said above give up > >now. > >>> >> >>> >>> >> > >>> >> >>> >>> >> — > >>> >> >>> >>> >> Reply to this email directly, view it on GitHub > >>> >> >>> >>> >> > >>> >> >>> >>> > >>> >> >>> > >>> >> >>>>< > >>> #35 (comment) > >< > >>> #35 (comment) > >> > >>> >> >, > >>> >> >>> >>> >or > >>> >> >>> >>> >> unsubscribe > >>> >> >>> >>> >> > >>> >> >>> >>> >< > >>> >> >>> >>> > >>> >> >>> >> > >>> >> >>> > >>> >> > > >>> >> > >>> > > > https://github.com/notifications/unsubscribe-auth/AN4GHPSSWORQMO6CGL6XQV3WUKDJNANCNFSM6AAAAAAUHJSYXI > >>> >> >>> >>> > > >>> >> >>> >>> >> . > >>> >> >>> >>> >> You are receiving this because you authored the > >>> >> >thread.Message > >>> >> >>> >>ID: > >>> >> >>> >>> >> ***@***.*** <mailto:***@***.***> > > >>> >> >>> >>> >> > >>> >> >>> >>> > > >>> >> >>> >>> > > >>> >> >>> >>> >-- > >>> >> >>> >>> >Reply to this email directly or view it on GitHub: > >>> >> >>> >>> > >>> >> > >>>#35 (comment) > >>> >> >>> >>> >You are receiving this because you commented. > >>> >> >>> >>> > > >>> >> >>> >>> >Message ID: ***@***.*** <mailto:***@***.***> > > >>> >> >>> >>> > >>> >> >>> >>> — > >>> >> >>> >>> Reply to this email directly, view it on GitHub > >>> >> >>> >>> > >>> >> >>> > >>> >> >>>< > >>> > >#35 (comment)>, > >>> >> >>> >>or > >>> >> >>> >>> unsubscribe > >>> >> >>> >>> > >>> >> >>> >>< > >>> >> >>> > >>> >> > > >>> >> > >>> > > > https://github.com/notifications/unsubscribe-auth/AN4GHPWOTGSC3DO2F7TN4M3WUK6FHANCNFSM6AAAAAAUHJSYXI > >>> >> >>> > > >>> >> >>> >>> . > >>> >> >>> >>> You are receiving this because you authored the > >thread.Message > >>> >> >ID: > >>> >> >>> >>> ***@***.*** <mailto:***@***.***> > > >>> >> >>> >>> > >>> >> >>> >> > >>> >> >>> >> > >>> >> >>> >>-- > >>> >> >>> >>Reply to this email directly or view it on GitHub: > >>> >> >>> > >>> >> > >>>>#35 (comment) > >>> >> >>> >>You are receiving this because you commented. > >>> >> >>> >> > >>> >> >>> >>Message ID: ***@***.*** <mailto:***@***.***> > > >>> >> >>> > >>> >> >>> — > >>> >> >>> Reply to this email directly, view it on GitHub > >>> >> >>> > >>> >> > >><#35 (comment) > >>> >, > >>> >> >>> or unsubscribe > >>> >> >>> > >>> >> >< > >>> >> > >>> > > > https://github.com/notifications/unsubscribe-auth/AN4GHPWDEQVBRFCQWOYLZOLWULYNPANCNFSM6AAAAAAUHJSYXI > >>> >> > > >>> >> >>> . > >>> >> >>> You are receiving this because you authored the > >thread.Message ID: > >>> >> >>> ***@***.*** <mailto:***@***.***> > > >>> >> >>> > >>> >> >> > >>> >> > > >>> >> > > >>> >> >-- > >>> >> >Reply to this email directly or view it on GitHub: > >>> >> > >>#35 (comment) > >>> >> >You are receiving this because you commented. > >>> >> > > >>> >> >Message ID: ***@***.*** <mailto:***@***.***> > > >>> >> > >>> >> — > >>> >> Reply to this email directly, view it on GitHub > >>> >> > ><#35 (comment)>, > >>> >> or unsubscribe > >>> >> < > >>> > > > https://github.com/notifications/unsubscribe-auth/AN4GHPWNBGQWDHVC25NK6GLWUVN2ZANCNFSM6AAAAAAUHJSYXI > >>> > > >>> >> . > >>> >> You are receiving this because you authored the thread.Message > >ID: > >>> >> ***@***.*** <mailto:***@***.***> > > >>> >> > >>> > > >>> > >>> > >>> > >>> — > >>> Reply to this email directly, view it on GitHub < > >>> #35 (comment)> > >, > >>> or unsubscribe < > >>> > > > https://github.com/notifications/unsubscribe-auth/AIRU2WZ6QZ2JTH4S7JDX2OLWU2QWFANCNFSM6AAAAAAUHJSYXI > > > >>> . > >>> You are receiving this because you commented. < > >>> > > > https://github.com/notifications/beacon/AIRU2W6ZSCHUD2NWHFVREOTWU2QWFA5CNFSM6AAAAAAUHJSYXKWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTST5ANTO.gif > > > >>> Message ID: < ***@***.***> ***@***.***> > >>> > >>> — > >>> Reply to this email directly, view it on GitHub > >>> > ><#35 (comment)>, > >>> or unsubscribe > >>> > >< > https://github.com/notifications/unsubscribe-auth/AN4GHPWVQWX2H6DMZ7ZWXZTWU3B2XANCNFSM6AAAAAAUHJSYXI > > > >>> . > >>> You are receiving this because you authored the thread.Message ID: > >>> ***@***.***> > >>> > >> > > > > > >-- > >Reply to this email directly or view it on GitHub: > >#35 (comment) > >You are receiving this because you commented. > > > >Message ID: ***@***.***> > > — > Reply to this email directly, view it on GitHub > <#35 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AN4GHPQ66E3C37NVCBNLY4LWVGGSVANCNFSM6AAAAAAUHJSYXI> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

On 1 Feb 2023, 08:20, at 08:20, pdbayes ***@***.***> wrote: This is the sellers response, I have pointed out that you need a different design for the external components for the higher frequency band and also that the antenna should be half the length. New message from: hol-5376 <https://www.ebay.co.uk/ulk/usr/hol-5376?mkevt=1&mkpid=0&emsid=e11051.m44.l1181&mkcid=7&ch=osgood&euid=d67b2f6f16d4484780ed2f0a8fed1e3e&bu=45544770190&osub=-1%7E1&crd=20230131165028&segname=11051> (18[image: YELLOW_STAR Star]) <https://www.ebay.co.uk/fdbk/feedback_profile/hol-5376?mkevt=1&mkpid=0&emsid=e11051.m44.l1183&mkcid=7&ch=osgood&euid=d67b2f6f16d4484780ed2f0a8fed1e3e&bu=45544770190&osub=-1%7E1&crd=20230131165028&segname=11051> Are you using Arduino to program it? If so what library? I've used the Elechouse library, and then you can use the .setMHZ() function to set the frequency You can enter any number in the range 779 - 928 MHz You can have a look here for some examples, and a good guide: https://github.com/LSatan/SmartRC-CC1101-Driver-Lib On Tue, 31 Jan 2023, 22:48 Paul Bayes, ***@***.***> wrote: > That's a good point. It doesn't say which of the frequencies it's > configured for. > I'll mail him. Pain in the bum. > > On Tue, 31 Jan 2023, 22:26 Peter Price, ***@***.***> wrote: > >> While the cc1101 will operate in all those frequency bands the circuit >> between the chip and antenna is different. >> >> It's possible that the module you've bought is configured for 433 MHz. >> It's very unlikely that you can buy a module that will work at all >> frequencies. >> >> You should be able to tell by looking closely at the layout of the >> components and comparing it to the TI documentation for the CC1101. >> >> ⁣Get BlueMail for Android ​ >> >> On 31 Jan 2023, 21:04, at 21:04, pdbayes ***@***.***> wrote: >> >Hi >> > >> >I assume if wired correctly and firmware loaded, I should see some data >> >in >> >the serial monitor? >> >I got one of these in the end and cross referenced your connection >> >instruction with the E07. >> > >> https://www.ebay.co.uk/itm/394035907922?mkcid=16&mkevt=1&mkrid=711-127632-2357-0&ssspo=meql5djjqne&sssrc=2349624&ssuid=b_r4gulfrre&var=&widget_ver=artemis&media=COPY >> > >> >Currently I only get the firmware version in the monitor. >> > >> >On Sun, 29 Jan 2023, 21:16 Paul Bayes, ***@***.***> wrote: >> > >> >> Thanks for your help. I'll give it a go later this week. >> >> >> >> On Sun, 29 Jan 2023, 19:42 Peter Price, ***@***.***> wrote: >> >> >> >>> This is the pinout for the Leonardo I’m referring to and the E07 >> >radio >> >>> module >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> You need to connect the following >> >>> >> >>> >> >>> >> >>> Leonardo E07 >> >>> >> >>> D0/RX 14 >> >>> >> >>> D1/TX 15 >> >>> >> >>> 3V3 9 >> >>> >> >>> GND 12 >> >>> >> >>> D10/PB6/SS 19 >> >>> >> >>> >> >>> >> >>> And from the ICSP header (check online for ICSP pinout) >> >>> >> >>> MOSI 17 >> >>> >> >>> MISO 16 >> >>> >> >>> SCK 18 >> >>> >> >>> >> >>> >> >>> Some of the E07 pins are probably available elsewhere on the dev >> >card. >> >>> >> >>> >> >>> >> >>> Don’t forget you need to make sure the STM8 doesn’t try to access >> >the E07 >> >>> at the same time as the Leonardo >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> From: pdbayes ***@***.*** >> >>> Sent: 29 January 2023 17:16 >> >>> To: ghoti57/evofw3 ***@***.***> >> >>> Cc: Peter Price ***@***.***>; Comment ***@***.***> >> >>> Subject: Re: [ghoti57/evofw3] STM8 (Issue #35) >> >>> >> >>> >> >>> >> >>> Hi. Got my Leonardo board, serial monitor reports evofw3 0.7.1. >> >>> Can you let me know the connections please. >> >>> Thank you >> >>> >> >>> >> >>> >> >>> On Sat, 28 Jan 2023, 19:18 Paul Bayes, ***@***.*** >> ><mailto:***@***.***> >> >>> > wrote: >> >>> >> >>> > Thanks. I've ordered a Leonardo as I have a prototype shield in >> >this >> >>> > format, which might help keep things tidy. >> >>> > >> >>> > On Sat, 28 Jan 2023, 18:06 Peter Price, ***@***.*** >> ><mailto:***@***.***> >> >>> > wrote: >> >>> > >> >>> >> You want something with an atmega32u4 processor. This will have >> >a >> >>> direct >> >>> >> usb interface to the host (no driver required) and leaves the HW >> >UART >> >>> free >> >>> >> to connect to the CC1101. >> >>> >> >> >>> >> Avoid atmega328 based devices. >> >>> >> >> >>> >> When you have it let me know exactly what you have and I'll tell >> >you >> >>> the >> >>> >> connections you need. >> >>> >> >> >>> >> ⁣Get BlueMail for Android ​ >> >>> >> >> >>> >> On 28 Jan 2023, 16:08, at 16:08, pdbayes ***@***.*** >> ><mailto:***@***.***> >> >>> > wrote: >> >>> >> >Last question I promise. I have a different recover now with no >> >MCU. >> >>> >> >Which >> >>> >> >MCU have you found works best. I have an old cloned Nano but It >> >won't >> >>> >> >load >> >>> >> >the sketch. I think it has a Chinese rip off usb chip that's not >> >great >> >>> >> >and >> >>> >> >that is causing issues. Would the latest Nano be a good choice. >> >>> >> > >> >>> >> >On Fri, 27 Jan 2023, 06:57 Paul Bayes, ***@***.*** >> ><mailto:***@***.***> >> >>> > wrote: >> >>> >> > >> >>> >> >> I have an Uno so should be ok. Thanks for your help >> >>> >> >> >> >>> >> >> On Thu, 26 Jan 2023, 22:06 Peter Price, ***@***.*** >> ><mailto:***@***.***> >> >>> > wrote: >> >>> >> >> >> >>> >> >>> Just thought. >> >>> >> >>> >> >>> >> >>> The power to the e7 will have to come from the Arduino. >> >>> >> >>> >> >>> >> >>> It will also be connected to the STM8 so you need to be sure >> >that >> >>> >> >it >> >>> >> >>> doesn't configure it's GOIOs in such a way that it >> >interferes >> >>> >> >>> >> >>> >> >>> ⁣Get BlueMail for Android ​ >> >>> >> >>> >> >>> >> >>> On 26 Jan 2023, 22:00, at 22:00, Peter Price ***@***.*** >> ><mailto:***@***.***> >> >>> > wrote: >> >>> >> >>> >If you have an Arduino with an atmega32u4 or a 16MHz >> >atmega328p >> >>> and >> >>> >> >you >> >>> >> >>> >connect it correctly it will work with no code changes. >> >>> >> >>> > >> >>> >> >>> >If you only have an 8MHz atmega328p it won't. >> >>> >> >>> > >> >>> >> >>> >⁣Get BlueMail for Android ​ >> >>> >> >>> > >> >>> >> >>> >On 26 Jan 2023, 20:00, at 20:00, pdbayes ***@***.*** >> ><mailto:***@***.***> >> >>> > >> >>> >> >>> >wrote: >> >>> >> >>> >>Hmmm. I wonder if I could hard wire the GDO pins from the >> >e07 >> >>> >> >module >> >>> >> >>> >to >> >>> >> >>> >>an >> >>> >> >>> >>Arduino I have spare? Will depend on what the STM8 is doing >> >on >> >>> >> >those >> >>> >> >>> >>pins >> >>> >> >>> >>or any intermediate components. Or maybe using software on >> >the >> >>> >> >STM8 >> >>> >> >>> >>the >> >>> >> >>> >>recieved data could be sent as is to an io pin. >> >>> >> >>> >> >> >>> >> >>> >>On Thu, 26 Jan 2023, 18:22 Peter Price, ***@***.*** >> ><mailto:***@***.***> >> >>> > wrote: >> >>> >> >>> >> >> >>> >> >>> >>> I think you've misunderstood about the UART in the >> >context of >> >>> >> >>> >>evofw3. >> >>> >> >>> >>> >> >>> >> >>> >>> The bitstream that comes out of the cc1101 in an evohome >> >>> >> >environment >> >>> >> >>> >>has >> >>> >> >>> >>> effectively been generated by UARTs in the Evo devices >> >>> >> >(controller, >> >>> >> >>> >>rad >> >>> >> >>> >>> stats, thermostats etc) >> >>> >> >>> >>> >> >>> >> >>> >>> This means you need a UART interface in the STM8 facing >> >the >> >>> >> >CC1101. >> >>> >> >>> >>> >> >>> >> >>> >>> On your Dev board the HW UART in the STM8 is almost >> >certainly >> >>> >> >>> >>connected to >> >>> >> >>> >>> the USB connector on the board. >> >>> >> >>> >>> >> >>> >> >>> >>> This means the connection to GDO0 and GD02 of the CC1101 >> >will >> >>> >> >be >> >>> >> >>> >>using two >> >>> >> >>> >>> ordinary GPIO signals. That means you have to implement a >> >SW >> >>> >> >UART >> >>> >> >>> >in >> >>> >> >>> >>the >> >>> >> >>> >>> STM8 to decode the bitstream. You have to be able to >> >>> >> >synchronise >> >>> >> >>> >>with the >> >>> >> >>> >>> stop/start bits in the bitstream so that you can identify >> >and >> >>> >> >>> >extract >> >>> >> >>> >>the >> >>> >> >>> >>> real data. >> >>> >> >>> >>> >> >>> >> >>> >>> You are not dealing with a synchronous system. It's >> >>> >> >asynchronous >> >>> >> >>> >>because >> >>> >> >>> >>> all the devices have their own clock and they're all >> >slightly >> >>> >> >>> >>different. >> >>> >> >>> >>> >> >>> >> >>> >>> You're dealing with a bit stream at 38400 baud with >> >significant >> >>> >> >>> >>jitter >> >>> >> >>> >>> generated by some of the devices you are listening to. >> >>> >> >>> >>> >> >>> >> >>> >>> I very much doubt that the example software will get >> >anywhere >> >>> >> >near >> >>> >> >>> >>> extracting the data you need. >> >>> >> >>> >>> >> >>> >> >>> >>> >> >>> >> >>> >>> >> >>> >> >>> >>> ⁣Get BlueMail for Android ​ >> >>> >> >>> >>> >> >>> >> >>> >>> On 26 Jan 2023, 15:04, at 15:04, pdbayes ***@***.*** >> ><mailto:***@***.***> >> >>> > wrote: >> >>> >> >>> >>> >Thanks for the advice. >> >>> >> >>> >>> >The dev board is this: >> >>> >> >>> >>> >https://www.ebyte.com/en/product-view-news.html?id=1691 >> >>> >> >>> >>> >All the UART side of things should be handled and I was >> >hoping >> >>> >> >I >> >>> >> >>> >>would >> >>> >> >>> >>> >just >> >>> >> >>> >>> >have a stream of bits to deal with on the pi/pc. They >> >say it >> >>> >> >comes >> >>> >> >>> >>> >with >> >>> >> >>> >>> >example software to do this but it is within a >> >commercial IDE >> >>> >> >you >> >>> >> >>> >>have >> >>> >> >>> >>> >to >> >>> >> >>> >>> >pay for. It has a free trial so hopefully that will give >> >me >> >>> >> >enough >> >>> >> >>> >>time >> >>> >> >>> >>> >to >> >>> >> >>> >>> >get it working. >> >>> >> >>> >>> > >> >>> >> >>> >>> >On Thu, 26 Jan 2023 at 14:32, Peter Price ***@***.*** >> ><mailto:***@***.***> >> >>> > wrote: >> >>> >> >>> >>> > >> >>> >> >>> >>> >> Good luck with that :-) >> >>> >> >>> >>> >> >> >>> >> >>> >>> >> The code has a lot of atmega specific code for the >> >hardware >> >>> >> >>> >>> >interface. >> >>> >> >>> >>> >> Because of the overhead the code doesn't use the >> >Arduino IO >> >>> >> >>> >>functions >> >>> >> >>> >>> >but >> >>> >> >>> >>> >> drives the GPIO pins directly via the registers. >> >>> >> >>> >>> >> >> >>> >> >>> >>> >> TX uses the SPI interface to fill the cc1101 TX fifo, >> >but, >> >>> >> >>> >because >> >>> >> >>> >>of >> >>> >> >>> >>> >the >> >>> >> >>> >>> >> jitter on the incoming signals from the other devices, >> >you >> >>> >> >can't >> >>> >> >>> >>use >> >>> >> >>> >>> >the >> >>> >> >>> >>> >> cc1101 rx fifo to capture the data because it assumes >> >>> >> >everything >> >>> >> >>> >>is >> >>> >> >>> >>> >> synchronous. >> >>> >> >>> >>> >> >> >>> >> >>> >>> >> If you try a port then I suggest you get the SPI >> >interface >> >>> to >> >>> >> >the >> >>> >> >>> >>> >CC1101 >> >>> >> >>> >>> >> working first and then the HW UART interface between >> >the STM >> >>> >> >and >> >>> >> >>> >>the >> >>> >> >>> >>> >> CC1101. This is just an ISR triggered by the UART that >> >reads >> >>> >> >the >> >>> >> >>> >>UART >> >>> >> >>> >>> >RX >> >>> >> >>> >>> >> data into a buffer. >> >>> >> >>> >>> >> >> >>> >> >>> >>> >> If the STM hasn't got a HW UART available then you'll >> >need >> >>> to >> >>> >> >be >> >>> >> >>> >>good >> >>> >> >>> >>> >at >> >>> >> >>> >>> >> coding. I suspect the STM8 HW UART has been connected >> >to the >> >>> >> >host >> >>> >> >>> >>> >USB >> >>> >> >>> >>> >> interface so this is going to be the case. >> >>> >> >>> >>> >> >> >>> >> >>> >>> >> The atmega328p SW UART code uses a HW interrupt to >> >capture >> >>> >> >the >> >>> >> >>> >>timing >> >>> >> >>> >>> >of >> >>> >> >>> >>> >> the signal edges and then a SW trap to process the >> >captured >> >>> >> >data >> >>> >> >>> >>> >edges to >> >>> >> >>> >>> >> generate an RX byte. This is very processor heavy and >> >every >> >>> >> >cycle >> >>> >> >>> >>is >> >>> >> >>> >>> >> critical to keep up with the data when it arrives. The >> >SW >> >>> >> >UART >> >>> >> >>> >>won't >> >>> >> >>> >>> >work >> >>> >> >>> >>> >> on an atmega clocked at less than 16MHz because there >> >aren't >> >>> >> >>> >>enough >> >>> >> >>> >>> >> instruction cycles available. >> >>> >> >>> >>> >> >> >>> >> >>> >>> >> The SW UART code is not as good at RXing radio >> >messages as >> >>> >> >the HW >> >>> >> >>> >>> >UART >> >>> >> >>> >>> >> code. >> >>> >> >>> >>> >> >> >>> >> >>> >>> >> Using a simple USB logic analyser ( e.g. >> >>> >> >>> >>> >> >> >>> >> >>> >>> > >> >>> >> >>> >>> >> >>> >> >>> >> >> >>> >> >>> >> >>> >> > >> >>> >> >> >>> >> > >> https://www.amazon.co.uk/Hobby-Components-24MHz-Analyser-1-1-16/dp/B00DAYAREW >> >>> >> >>> >>> ) >> >>> >> >>> >>> >> there are some debug lines still in the code that you >> >can >> >>> use >> >>> >> >to >> >>> >> >>> >>> >drive >> >>> >> >>> >>> >> spare GPIO pins that will show you how much processor >> >time >> >>> >> >you're >> >>> >> >>> >>> >using in >> >>> >> >>> >>> >> the HW and SW ISR functions. >> >>> >> >>> >>> >> >> >>> >> >>> >>> >> The frame, message and host interface code should >> >work >> >>> >> >without >> >>> >> >>> >>> >significant >> >>> >> >>> >>> >> changes. >> >>> >> >>> >>> >> >> >>> >> >>> >>> >> That's all the help I can offer since I have zero STM >> >>> >> >knowledge. >> >>> >> >>> >>> >> >> >>> >> >>> >>> >> If you don't understand what I've said above give up >> >now. >> >>> >> >>> >>> >> >> >>> >> >>> >>> >> — >> >>> >> >>> >>> >> Reply to this email directly, view it on GitHub >> >>> >> >>> >>> >> >> >>> >> >>> >>> >> >>> >> >>> >> >>> >> >>>>< >> >>> #35 (comment) >> >< >> >>> #35 (comment) >> >> >> >>> >> >, >> >>> >> >>> >>> >or >> >>> >> >>> >>> >> unsubscribe >> >>> >> >>> >>> >> >> >>> >> >>> >>> >< >> >>> >> >>> >>> >> >>> >> >>> >> >> >>> >> >>> >> >>> >> > >> >>> >> >> >>> >> > >> https://github.com/notifications/unsubscribe-auth/AN4GHPSSWORQMO6CGL6XQV3WUKDJNANCNFSM6AAAAAAUHJSYXI >> >>> >> >>> >>> > >> >>> >> >>> >>> >> . >> >>> >> >>> >>> >> You are receiving this because you authored the >> >>> >> >thread.Message >> >>> >> >>> >>ID: >> >>> >> >>> >>> >> ***@***.*** <mailto:***@***.***> > >> >>> >> >>> >>> >> >> >>> >> >>> >>> > >> >>> >> >>> >>> > >> >>> >> >>> >>> >-- >> >>> >> >>> >>> >Reply to this email directly or view it on GitHub: >> >>> >> >>> >>> >> >>> >> >> >>>#35 (comment) >> >>> >> >>> >>> >You are receiving this because you commented. >> >>> >> >>> >>> > >> >>> >> >>> >>> >Message ID: ***@***.*** <mailto:***@***.***> > >> >>> >> >>> >>> >> >>> >> >>> >>> — >> >>> >> >>> >>> Reply to this email directly, view it on GitHub >> >>> >> >>> >>> >> >>> >> >>> >> >>> >> >>>< >> >>> >> >#35 (comment)>, >> >>> >> >>> >>or >> >>> >> >>> >>> unsubscribe >> >>> >> >>> >>> >> >>> >> >>> >>< >> >>> >> >>> >> >>> >> > >> >>> >> >> >>> >> > >> https://github.com/notifications/unsubscribe-auth/AN4GHPWOTGSC3DO2F7TN4M3WUK6FHANCNFSM6AAAAAAUHJSYXI >> >>> >> >>> > >> >>> >> >>> >>> . >> >>> >> >>> >>> You are receiving this because you authored the >> >thread.Message >> >>> >> >ID: >> >>> >> >>> >>> ***@***.*** <mailto:***@***.***> > >> >>> >> >>> >>> >> >>> >> >>> >> >> >>> >> >>> >> >> >>> >> >>> >>-- >> >>> >> >>> >>Reply to this email directly or view it on GitHub: >> >>> >> >>> >> >>> >> >> >>>>#35 (comment) >> >>> >> >>> >>You are receiving this because you commented. >> >>> >> >>> >> >> >>> >> >>> >>Message ID: ***@***.*** <mailto:***@***.***> > >> >>> >> >>> >> >>> >> >>> — >> >>> >> >>> Reply to this email directly, view it on GitHub >> >>> >> >>> >> >>> >> >> >><#35 (comment) >> >>> >, >> >>> >> >>> or unsubscribe >> >>> >> >>> >> >>> >> >< >> >>> >> >> >>> >> > >> https://github.com/notifications/unsubscribe-auth/AN4GHPWDEQVBRFCQWOYLZOLWULYNPANCNFSM6AAAAAAUHJSYXI >> >>> >> > >> >>> >> >>> . >> >>> >> >>> You are receiving this because you authored the >> >thread.Message ID: >> >>> >> >>> ***@***.*** <mailto:***@***.***> > >> >>> >> >>> >> >>> >> >> >> >>> >> > >> >>> >> > >> >>> >> >-- >> >>> >> >Reply to this email directly or view it on GitHub: >> >>> >> >> >>#35 (comment) >> >>> >> >You are receiving this because you commented. >> >>> >> > >> >>> >> >Message ID: ***@***.*** <mailto:***@***.***> > >> >>> >> >> >>> >> — >> >>> >> Reply to this email directly, view it on GitHub >> >>> >> >> ><#35 (comment)>, >> >>> >> or unsubscribe >> >>> >> < >> >>> >> > >> https://github.com/notifications/unsubscribe-auth/AN4GHPWNBGQWDHVC25NK6GLWUVN2ZANCNFSM6AAAAAAUHJSYXI >> >>> > >> >>> >> . >> >>> >> You are receiving this because you authored the thread.Message >> >ID: >> >>> >> ***@***.*** <mailto:***@***.***> > >> >>> >> >> >>> > >> >>> >> >>> >> >>> >> >>> — >> >>> Reply to this email directly, view it on GitHub < >> >>> #35 (comment)> >> >, >> >>> or unsubscribe < >> >>> >> > >> https://github.com/notifications/unsubscribe-auth/AIRU2WZ6QZ2JTH4S7JDX2OLWU2QWFANCNFSM6AAAAAAUHJSYXI >> > >> >>> . >> >>> You are receiving this because you commented. < >> >>> >> > >> https://github.com/notifications/beacon/AIRU2W6ZSCHUD2NWHFVREOTWU2QWFA5CNFSM6AAAAAAUHJSYXKWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTST5ANTO.gif >> > >> >>> Message ID: < ***@***.***> ***@***.***> >> >>> >> >>> — >> >>> Reply to this email directly, view it on GitHub >> >>> >> ><#35 (comment)>, >> >>> or unsubscribe >> >>> >> >< >> https://github.com/notifications/unsubscribe-auth/AN4GHPWVQWX2H6DMZ7ZWXZTWU3B2XANCNFSM6AAAAAAUHJSYXI >> > >> >>> . >> >>> You are receiving this because you authored the thread.Message ID: >> >>> ***@***.***> >> >>> >> >> >> > >> > >> >-- >> >Reply to this email directly or view it on GitHub: >> >#35 (comment) >> >You are receiving this because you commented. >> > >> >Message ID: ***@***.***> >> >> — >> Reply to this email directly, view it on GitHub >> <#35 (comment)>, >> or unsubscribe >> <https://github.com/notifications/unsubscribe-auth/AN4GHPQ66E3C37NVCBNLY4LWVGGSVANCNFSM6AAAAAAUHJSYXI> >> . >> You are receiving this because you authored the thread.Message ID: >> ***@***.***> >> > -- Reply to this email directly or view it on GitHub: #35 (comment) You are receiving this because you commented. Message ID: ***@***.***>

On Wed, 1 Feb 2023, 18:11 Peter Price, ***@***.***> wrote: Evofw3 configured the card for 868MHz. But t the point is the antenna is not optimised for that frequency. The pictures on the site show the card is printed with 433MHz When I was looking, all the modules that looked like this appeared to be 433MHz ⁣Get BlueMail for Android ​ On 1 Feb 2023, 08:20, at 08:20, pdbayes ***@***.***> wrote: >This is the sellers response, I have pointed out that you need a >different >design for the external components for the higher frequency band and >also >that the antenna should be half the length. >New message from: hol-5376 >< https://www.ebay.co.uk/ulk/usr/hol-5376?mkevt=1&mkpid=0&emsid=e11051.m44.l1181&mkcid=7&ch=osgood&euid=d67b2f6f16d4484780ed2f0a8fed1e3e&bu=45544770190&osub=-1%7E1&crd=20230131165028&segname=11051 > > (18[image: YELLOW_STAR Star]) >< https://www.ebay.co.uk/fdbk/feedback_profile/hol-5376?mkevt=1&mkpid=0&emsid=e11051.m44.l1183&mkcid=7&ch=osgood&euid=d67b2f6f16d4484780ed2f0a8fed1e3e&bu=45544770190&osub=-1%7E1&crd=20230131165028&segname=11051 > > >Are you using Arduino to program it? > >If so what library? >I've used the Elechouse library, and then you can use the .setMHZ() >function to set the frequency > >You can enter any number in the range 779 - 928 MHz > >You can have a look here for some examples, and a good guide: >https://github.com/LSatan/SmartRC-CC1101-Driver-Lib > > >On Tue, 31 Jan 2023, 22:48 Paul Bayes, ***@***.***> wrote: > >> That's a good point. It doesn't say which of the frequencies it's >> configured for. >> I'll mail him. Pain in the bum. >> >> On Tue, 31 Jan 2023, 22:26 Peter Price, ***@***.***> wrote: >> >>> While the cc1101 will operate in all those frequency bands the >circuit >>> between the chip and antenna is different. >>> >>> It's possible that the module you've bought is configured for 433 >MHz. >>> It's very unlikely that you can buy a module that will work at all >>> frequencies. >>> >>> You should be able to tell by looking closely at the layout of the >>> components and comparing it to the TI documentation for the CC1101. >>> >>> ⁣Get BlueMail for Android ​ >>> >>> On 31 Jan 2023, 21:04, at 21:04, pdbayes ***@***.***> wrote: >>> >Hi >>> > >>> >I assume if wired correctly and firmware loaded, I should see some >data >>> >in >>> >the serial monitor? >>> >I got one of these in the end and cross referenced your connection >>> >instruction with the E07. >>> > >>> > https://www.ebay.co.uk/itm/394035907922?mkcid=16&mkevt=1&mkrid=711-127632-2357-0&ssspo=meql5djjqne&sssrc=2349624&ssuid=b_r4gulfrre&var=&widget_ver=artemis&media=COPY >>> > >>> >Currently I only get the firmware version in the monitor. >>> > >>> >On Sun, 29 Jan 2023, 21:16 Paul Bayes, ***@***.***> wrote: >>> > >>> >> Thanks for your help. I'll give it a go later this week. >>> >> >>> >> On Sun, 29 Jan 2023, 19:42 Peter Price, ***@***.***> wrote: >>> >> >>> >>> This is the pinout for the Leonardo I’m referring to and the >E07 >>> >radio >>> >>> module >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> You need to connect the following >>> >>> >>> >>> >>> >>> >>> >>> Leonardo E07 >>> >>> >>> >>> D0/RX 14 >>> >>> >>> >>> D1/TX 15 >>> >>> >>> >>> 3V3 9 >>> >>> >>> >>> GND 12 >>> >>> >>> >>> D10/PB6/SS 19 >>> >>> >>> >>> >>> >>> >>> >>> And from the ICSP header (check online for ICSP pinout) >>> >>> >>> >>> MOSI 17 >>> >>> >>> >>> MISO 16 >>> >>> >>> >>> SCK 18 >>> >>> >>> >>> >>> >>> >>> >>> Some of the E07 pins are probably available elsewhere on the >dev >>> >card. >>> >>> >>> >>> >>> >>> >>> >>> Don’t forget you need to make sure the STM8 doesn’t try to >access >>> >the E07 >>> >>> at the same time as the Leonardo >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> From: pdbayes ***@***.*** >>> >>> Sent: 29 January 2023 17:16 >>> >>> To: ghoti57/evofw3 ***@***.***> >>> >>> Cc: Peter Price ***@***.***>; Comment ***@***.***> >>> >>> Subject: Re: [ghoti57/evofw3] STM8 (Issue #35) >>> >>> >>> >>> >>> >>> >>> >>> Hi. Got my Leonardo board, serial monitor reports evofw3 0.7.1. >>> >>> Can you let me know the connections please. >>> >>> Thank you >>> >>> >>> >>> >>> >>> >>> >>> On Sat, 28 Jan 2023, 19:18 Paul Bayes, ***@***.*** >>> ><mailto:***@***.***> >>> >>> > wrote: >>> >>> >>> >>> > Thanks. I've ordered a Leonardo as I have a prototype shield >in >>> >this >>> >>> > format, which might help keep things tidy. >>> >>> > >>> >>> > On Sat, 28 Jan 2023, 18:06 Peter Price, ***@***.*** >>> ><mailto:***@***.***> >>> >>> > wrote: >>> >>> > >>> >>> >> You want something with an atmega32u4 processor. This will >have >>> >a >>> >>> direct >>> >>> >> usb interface to the host (no driver required) and leaves the >HW >>> >UART >>> >>> free >>> >>> >> to connect to the CC1101. >>> >>> >> >>> >>> >> Avoid atmega328 based devices. >>> >>> >> >>> >>> >> When you have it let me know exactly what you have and I'll >tell >>> >you >>> >>> the >>> >>> >> connections you need. >>> >>> >> >>> >>> >> ⁣Get BlueMail for Android ​ >>> >>> >> >>> >>> >> On 28 Jan 2023, 16:08, at 16:08, pdbayes ***@***.*** >>> ><mailto:***@***.***> >>> >>> > wrote: >>> >>> >> >Last question I promise. I have a different recover now with >no >>> >MCU. >>> >>> >> >Which >>> >>> >> >MCU have you found works best. I have an old cloned Nano but >It >>> >won't >>> >>> >> >load >>> >>> >> >the sketch. I think it has a Chinese rip off usb chip that's >not >>> >great >>> >>> >> >and >>> >>> >> >that is causing issues. Would the latest Nano be a good >choice. >>> >>> >> > >>> >>> >> >On Fri, 27 Jan 2023, 06:57 Paul Bayes, ***@***.*** >>> ><mailto:***@***.***> >>> >>> > wrote: >>> >>> >> > >>> >>> >> >> I have an Uno so should be ok. Thanks for your help >>> >>> >> >> >>> >>> >> >> On Thu, 26 Jan 2023, 22:06 Peter Price, ***@***.*** >>> ><mailto:***@***.***> >>> >>> > wrote: >>> >>> >> >> >>> >>> >> >>> Just thought. >>> >>> >> >>> >>> >>> >> >>> The power to the e7 will have to come from the Arduino. >>> >>> >> >>> >>> >>> >> >>> It will also be connected to the STM8 so you need to be >sure >>> >that >>> >>> >> >it >>> >>> >> >>> doesn't configure it's GOIOs in such a way that it >>> >interferes >>> >>> >> >>> >>> >>> >> >>> ⁣Get BlueMail for Android ​ >>> >>> >> >>> >>> >>> >> >>> On 26 Jan 2023, 22:00, at 22:00, Peter Price ***@***.*** >>> ><mailto:***@***.***> >>> >>> > wrote: >>> >>> >> >>> >If you have an Arduino with an atmega32u4 or a 16MHz >>> >atmega328p >>> >>> and >>> >>> >> >you >>> >>> >> >>> >connect it correctly it will work with no code changes. >>> >>> >> >>> > >>> >>> >> >>> >If you only have an 8MHz atmega328p it won't. >>> >>> >> >>> > >>> >>> >> >>> >⁣Get BlueMail for Android ​ >>> >>> >> >>> > >>> >>> >> >>> >On 26 Jan 2023, 20:00, at 20:00, pdbayes ***@***.*** >>> ><mailto:***@***.***> >>> >>> > >>> >>> >> >>> >wrote: >>> >>> >> >>> >>Hmmm. I wonder if I could hard wire the GDO pins from >the >>> >e07 >>> >>> >> >module >>> >>> >> >>> >to >>> >>> >> >>> >>an >>> >>> >> >>> >>Arduino I have spare? Will depend on what the STM8 is >doing >>> >on >>> >>> >> >those >>> >>> >> >>> >>pins >>> >>> >> >>> >>or any intermediate components. Or maybe using software >on >>> >the >>> >>> >> >STM8 >>> >>> >> >>> >>the >>> >>> >> >>> >>recieved data could be sent as is to an io pin. >>> >>> >> >>> >> >>> >>> >> >>> >>On Thu, 26 Jan 2023, 18:22 Peter Price, ***@***.*** >>> ><mailto:***@***.***> >>> >>> > wrote: >>> >>> >> >>> >> >>> >>> >> >>> >>> I think you've misunderstood about the UART in the >>> >context of >>> >>> >> >>> >>evofw3. >>> >>> >> >>> >>> >>> >>> >> >>> >>> The bitstream that comes out of the cc1101 in an >evohome >>> >>> >> >environment >>> >>> >> >>> >>has >>> >>> >> >>> >>> effectively been generated by UARTs in the Evo >devices >>> >>> >> >(controller, >>> >>> >> >>> >>rad >>> >>> >> >>> >>> stats, thermostats etc) >>> >>> >> >>> >>> >>> >>> >> >>> >>> This means you need a UART interface in the STM8 >facing >>> >the >>> >>> >> >CC1101. >>> >>> >> >>> >>> >>> >>> >> >>> >>> On your Dev board the HW UART in the STM8 is almost >>> >certainly >>> >>> >> >>> >>connected to >>> >>> >> >>> >>> the USB connector on the board. >>> >>> >> >>> >>> >>> >>> >> >>> >>> This means the connection to GDO0 and GD02 of the >CC1101 >>> >will >>> >>> >> >be >>> >>> >> >>> >>using two >>> >>> >> >>> >>> ordinary GPIO signals. That means you have to >implement a >>> >SW >>> >>> >> >UART >>> >>> >> >>> >in >>> >>> >> >>> >>the >>> >>> >> >>> >>> STM8 to decode the bitstream. You have to be able to >>> >>> >> >synchronise >>> >>> >> >>> >>with the >>> >>> >> >>> >>> stop/start bits in the bitstream so that you can >identify >>> >and >>> >>> >> >>> >extract >>> >>> >> >>> >>the >>> >>> >> >>> >>> real data. >>> >>> >> >>> >>> >>> >>> >> >>> >>> You are not dealing with a synchronous system. It's >>> >>> >> >asynchronous >>> >>> >> >>> >>because >>> >>> >> >>> >>> all the devices have their own clock and they're all >>> >slightly >>> >>> >> >>> >>different. >>> >>> >> >>> >>> >>> >>> >> >>> >>> You're dealing with a bit stream at 38400 baud with >>> >significant >>> >>> >> >>> >>jitter >>> >>> >> >>> >>> generated by some of the devices you are listening >to. >>> >>> >> >>> >>> >>> >>> >> >>> >>> I very much doubt that the example software will get >>> >anywhere >>> >>> >> >near >>> >>> >> >>> >>> extracting the data you need. >>> >>> >> >>> >>> >>> >>> >> >>> >>> >>> >>> >> >>> >>> >>> >>> >> >>> >>> ⁣Get BlueMail for Android ​ >>> >>> >> >>> >>> >>> >>> >> >>> >>> On 26 Jan 2023, 15:04, at 15:04, pdbayes ***@***.*** >>> ><mailto:***@***.***> >>> >>> > wrote: >>> >>> >> >>> >>> >Thanks for the advice. >>> >>> >> >>> >>> >The dev board is this: >>> >>> >> >>> >>> >>https://www.ebyte.com/en/product-view-news.html?id=1691 >>> >>> >> >>> >>> >All the UART side of things should be handled and I >was >>> >hoping >>> >>> >> >I >>> >>> >> >>> >>would >>> >>> >> >>> >>> >just >>> >>> >> >>> >>> >have a stream of bits to deal with on the pi/pc. >They >>> >say it >>> >>> >> >comes >>> >>> >> >>> >>> >with >>> >>> >> >>> >>> >example software to do this but it is within a >>> >commercial IDE >>> >>> >> >you >>> >>> >> >>> >>have >>> >>> >> >>> >>> >to >>> >>> >> >>> >>> >pay for. It has a free trial so hopefully that will >give >>> >me >>> >>> >> >enough >>> >>> >> >>> >>time >>> >>> >> >>> >>> >to >>> >>> >> >>> >>> >get it working. >>> >>> >> >>> >>> > >>> >>> >> >>> >>> >On Thu, 26 Jan 2023 at 14:32, Peter Price >***@***.*** >>> ><mailto:***@***.***> >>> >>> > wrote: >>> >>> >> >>> >>> > >>> >>> >> >>> >>> >> Good luck with that :-) >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> The code has a lot of atmega specific code for >the >>> >hardware >>> >>> >> >>> >>> >interface. >>> >>> >> >>> >>> >> Because of the overhead the code doesn't use the >>> >Arduino IO >>> >>> >> >>> >>functions >>> >>> >> >>> >>> >but >>> >>> >> >>> >>> >> drives the GPIO pins directly via the registers. >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> TX uses the SPI interface to fill the cc1101 TX >fifo, >>> >but, >>> >>> >> >>> >because >>> >>> >> >>> >>of >>> >>> >> >>> >>> >the >>> >>> >> >>> >>> >> jitter on the incoming signals from the other >devices, >>> >you >>> >>> >> >can't >>> >>> >> >>> >>use >>> >>> >> >>> >>> >the >>> >>> >> >>> >>> >> cc1101 rx fifo to capture the data because it >assumes >>> >>> >> >everything >>> >>> >> >>> >>is >>> >>> >> >>> >>> >> synchronous. >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> If you try a port then I suggest you get the SPI >>> >interface >>> >>> to >>> >>> >> >the >>> >>> >> >>> >>> >CC1101 >>> >>> >> >>> >>> >> working first and then the HW UART interface >between >>> >the STM >>> >>> >> >and >>> >>> >> >>> >>the >>> >>> >> >>> >>> >> CC1101. This is just an ISR triggered by the UART >that >>> >reads >>> >>> >> >the >>> >>> >> >>> >>UART >>> >>> >> >>> >>> >RX >>> >>> >> >>> >>> >> data into a buffer. >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> If the STM hasn't got a HW UART available then >you'll >>> >need >>> >>> to >>> >>> >> >be >>> >>> >> >>> >>good >>> >>> >> >>> >>> >at >>> >>> >> >>> >>> >> coding. I suspect the STM8 HW UART has been >connected >>> >to the >>> >>> >> >host >>> >>> >> >>> >>> >USB >>> >>> >> >>> >>> >> interface so this is going to be the case. >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> The atmega328p SW UART code uses a HW interrupt >to >>> >capture >>> >>> >> >the >>> >>> >> >>> >>timing >>> >>> >> >>> >>> >of >>> >>> >> >>> >>> >> the signal edges and then a SW trap to process >the >>> >captured >>> >>> >> >data >>> >>> >> >>> >>> >edges to >>> >>> >> >>> >>> >> generate an RX byte. This is very processor heavy >and >>> >every >>> >>> >> >cycle >>> >>> >> >>> >>is >>> >>> >> >>> >>> >> critical to keep up with the data when it arrives. >The >>> >SW >>> >>> >> >UART >>> >>> >> >>> >>won't >>> >>> >> >>> >>> >work >>> >>> >> >>> >>> >> on an atmega clocked at less than 16MHz because >there >>> >aren't >>> >>> >> >>> >>enough >>> >>> >> >>> >>> >> instruction cycles available. >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> The SW UART code is not as good at RXing radio >>> >messages as >>> >>> >> >the HW >>> >>> >> >>> >>> >UART >>> >>> >> >>> >>> >> code. >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> Using a simple USB logic analyser ( e.g. >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> > >>> >>> >> >>> >>> >>> >>> >> >>> >> >>> >>> >> >>> >>> >>> >> > >>> >>> >> >>> >>> >>> > >>> > https://www.amazon.co.uk/Hobby-Components-24MHz-Analyser-1-1-16/dp/B00DAYAREW >>> >>> >> >>> >>> ) >>> >>> >> >>> >>> >> there are some debug lines still in the code that >you >>> >can >>> >>> use >>> >>> >> >to >>> >>> >> >>> >>> >drive >>> >>> >> >>> >>> >> spare GPIO pins that will show you how much >processor >>> >time >>> >>> >> >you're >>> >>> >> >>> >>> >using in >>> >>> >> >>> >>> >> the HW and SW ISR functions. >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> The frame, message and host interface code should >>> >work >>> >>> >> >without >>> >>> >> >>> >>> >significant >>> >>> >> >>> >>> >> changes. >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> That's all the help I can offer since I have zero >STM >>> >>> >> >knowledge. >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> If you don't understand what I've said above give >up >>> >now. >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> — >>> >>> >> >>> >>> >> Reply to this email directly, view it on GitHub >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >>> >>> >> >>> >>> >>> >> >>>>< >>> >>> >#35 (comment) >>> >< >>> >>> >#35 (comment) >>> >> >>> >>> >> >, >>> >>> >> >>> >>> >or >>> >>> >> >>> >>> >> unsubscribe >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >< >>> >>> >> >>> >>> >>> >>> >> >>> >> >>> >>> >> >>> >>> >>> >> > >>> >>> >> >>> >>> >>> > >>> > https://github.com/notifications/unsubscribe-auth/AN4GHPSSWORQMO6CGL6XQV3WUKDJNANCNFSM6AAAAAAUHJSYXI >>> >>> >> >>> >>> > >>> >>> >> >>> >>> >> . >>> >>> >> >>> >>> >> You are receiving this because you authored the >>> >>> >> >thread.Message >>> >>> >> >>> >>ID: >>> >>> >> >>> >>> >> ***@***.*** <mailto:***@***.***> > >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> > >>> >>> >> >>> >>> > >>> >>> >> >>> >>> >-- >>> >>> >> >>> >>> >Reply to this email directly or view it on GitHub: >>> >>> >> >>> >>> >>> >>> >> >>> >>>>#35 (comment) >>> >>> >> >>> >>> >You are receiving this because you commented. >>> >>> >> >>> >>> > >>> >>> >> >>> >>> >Message ID: ***@***.*** <mailto:***@***.***> > >>> >>> >> >>> >>> >>> >>> >> >>> >>> — >>> >>> >> >>> >>> Reply to this email directly, view it on GitHub >>> >>> >> >>> >>> >>> >>> >> >>> >>> >>> >> >>>< >>> >>> >>> >>#35 (comment)>, >>> >>> >> >>> >>or >>> >>> >> >>> >>> unsubscribe >>> >>> >> >>> >>> >>> >>> >> >>> >>< >>> >>> >> >>> >>> >>> >> > >>> >>> >> >>> >>> >>> > >>> > https://github.com/notifications/unsubscribe-auth/AN4GHPWOTGSC3DO2F7TN4M3WUK6FHANCNFSM6AAAAAAUHJSYXI >>> >>> >> >>> > >>> >>> >> >>> >>> . >>> >>> >> >>> >>> You are receiving this because you authored the >>> >thread.Message >>> >>> >> >ID: >>> >>> >> >>> >>> ***@***.*** <mailto:***@***.***> > >>> >>> >> >>> >>> >>> >>> >> >>> >> >>> >>> >> >>> >> >>> >>> >> >>> >>-- >>> >>> >> >>> >>Reply to this email directly or view it on GitHub: >>> >>> >> >>> >>> >>> >> >>> >>>>>#35 (comment) >>> >>> >> >>> >>You are receiving this because you commented. >>> >>> >> >>> >> >>> >>> >> >>> >>Message ID: ***@***.*** <mailto:***@***.***> > >>> >>> >> >>> >>> >>> >> >>> — >>> >>> >> >>> Reply to this email directly, view it on GitHub >>> >>> >> >>> >>> >>> >> >>> >>><#35 (comment) >>> >>> >, >>> >>> >> >>> or unsubscribe >>> >>> >> >>> >>> >>> >> >< >>> >>> >> >>> >>> >>> > >>> > https://github.com/notifications/unsubscribe-auth/AN4GHPWDEQVBRFCQWOYLZOLWULYNPANCNFSM6AAAAAAUHJSYXI >>> >>> >> > >>> >>> >> >>> . >>> >>> >> >>> You are receiving this because you authored the >>> >thread.Message ID: >>> >>> >> >>> ***@***.*** <mailto:***@***.***> > >>> >>> >> >>> >>> >>> >> >> >>> >>> >> > >>> >>> >> > >>> >>> >> >-- >>> >>> >> >Reply to this email directly or view it on GitHub: >>> >>> >> >>> >>>#35 (comment) >>> >>> >> >You are receiving this because you commented. >>> >>> >> > >>> >>> >> >Message ID: ***@***.*** <mailto:***@***.***> > >>> >>> >> >>> >>> >> — >>> >>> >> Reply to this email directly, view it on GitHub >>> >>> >> >>> >><#35 (comment)>, >>> >>> >> or unsubscribe >>> >>> >> < >>> >>> >>> > >>> > https://github.com/notifications/unsubscribe-auth/AN4GHPWNBGQWDHVC25NK6GLWUVN2ZANCNFSM6AAAAAAUHJSYXI >>> >>> > >>> >>> >> . >>> >>> >> You are receiving this because you authored the >thread.Message >>> >ID: >>> >>> >> ***@***.*** <mailto:***@***.***> > >>> >>> >> >>> >>> > >>> >>> >>> >>> >>> >>> >>> >>> — >>> >>> Reply to this email directly, view it on GitHub < >>> >>> >#35 (comment)> >>> >, >>> >>> or unsubscribe < >>> >>> >>> > >>> > https://github.com/notifications/unsubscribe-auth/AIRU2WZ6QZ2JTH4S7JDX2OLWU2QWFANCNFSM6AAAAAAUHJSYXI >>> > >>> >>> . >>> >>> You are receiving this because you commented. < >>> >>> >>> > >>> > https://github.com/notifications/beacon/AIRU2W6ZSCHUD2NWHFVREOTWU2QWFA5CNFSM6AAAAAAUHJSYXKWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTST5ANTO.gif >>> > >>> >>> Message ID: < ***@***.***> ***@***.***> >>> >>> >>> >>> — >>> >>> Reply to this email directly, view it on GitHub >>> >>> >>> >><#35 (comment)>, >>> >>> or unsubscribe >>> >>> >>> >< >>> > https://github.com/notifications/unsubscribe-auth/AN4GHPWVQWX2H6DMZ7ZWXZTWU3B2XANCNFSM6AAAAAAUHJSYXI >>> > >>> >>> . >>> >>> You are receiving this because you authored the thread.Message >ID: >>> >>> ***@***.***> >>> >>> >>> >> >>> > >>> > >>> >-- >>> >Reply to this email directly or view it on GitHub: >>> >>#35 (comment) >>> >You are receiving this because you commented. >>> > >>> >Message ID: ***@***.***> >>> >>> — >>> Reply to this email directly, view it on GitHub >>> ><#35 (comment)>, >>> or unsubscribe >>> >< https://github.com/notifications/unsubscribe-auth/AN4GHPQ66E3C37NVCBNLY4LWVGGSVANCNFSM6AAAAAAUHJSYXI > >>> . >>> You are receiving this because you authored the thread.Message ID: >>> ***@***.***> >>> >> > > >-- >Reply to this email directly or view it on GitHub: >#35 (comment) >You are receiving this because you commented. > >Message ID: ***@***.***> — Reply to this email directly, view it on GitHub <#35 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AN4GHPTQPA4ZFLA47AKROBTWVKRLRANCNFSM6AAAAAAUHJSYXI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

On Wed, 1 Feb 2023, 18:28 Paul Bayes, ***@***.***> wrote: I agree. See what he says. On Wed, 1 Feb 2023, 18:11 Peter Price, ***@***.***> wrote: > Evofw3 configured the card for 868MHz. > > But t the point is the antenna is not optimised for that frequency. > > The pictures on the site show the card is printed with 433MHz > > When I was looking, all the modules that looked like this appeared to be > 433MHz > > > > ⁣Get BlueMail for Android ​ > > On 1 Feb 2023, 08:20, at 08:20, pdbayes ***@***.***> wrote: > >This is the sellers response, I have pointed out that you need a > >different > >design for the external components for the higher frequency band and > >also > >that the antenna should be half the length. > >New message from: hol-5376 > >< > https://www.ebay.co.uk/ulk/usr/hol-5376?mkevt=1&mkpid=0&emsid=e11051.m44.l1181&mkcid=7&ch=osgood&euid=d67b2f6f16d4484780ed2f0a8fed1e3e&bu=45544770190&osub=-1%7E1&crd=20230131165028&segname=11051 > > > > (18[image: YELLOW_STAR Star]) > >< > https://www.ebay.co.uk/fdbk/feedback_profile/hol-5376?mkevt=1&mkpid=0&emsid=e11051.m44.l1183&mkcid=7&ch=osgood&euid=d67b2f6f16d4484780ed2f0a8fed1e3e&bu=45544770190&osub=-1%7E1&crd=20230131165028&segname=11051 > > > > > >Are you using Arduino to program it? > > > >If so what library? > >I've used the Elechouse library, and then you can use the .setMHZ() > >function to set the frequency > > > >You can enter any number in the range 779 - 928 MHz > > > >You can have a look here for some examples, and a good guide: > >https://github.com/LSatan/SmartRC-CC1101-Driver-Lib > > > > > >On Tue, 31 Jan 2023, 22:48 Paul Bayes, ***@***.***> wrote: > > > >> That's a good point. It doesn't say which of the frequencies it's > >> configured for. > >> I'll mail him. Pain in the bum. > >> > >> On Tue, 31 Jan 2023, 22:26 Peter Price, ***@***.***> wrote: > >> > >>> While the cc1101 will operate in all those frequency bands the > >circuit > >>> between the chip and antenna is different. > >>> > >>> It's possible that the module you've bought is configured for 433 > >MHz. > >>> It's very unlikely that you can buy a module that will work at all > >>> frequencies. > >>> > >>> You should be able to tell by looking closely at the layout of the > >>> components and comparing it to the TI documentation for the CC1101. > >>> > >>> ⁣Get BlueMail for Android ​ > >>> > >>> On 31 Jan 2023, 21:04, at 21:04, pdbayes ***@***.***> wrote: > >>> >Hi > >>> > > >>> >I assume if wired correctly and firmware loaded, I should see some > >data > >>> >in > >>> >the serial monitor? > >>> >I got one of these in the end and cross referenced your connection > >>> >instruction with the E07. > >>> > > >>> > > > https://www.ebay.co.uk/itm/394035907922?mkcid=16&mkevt=1&mkrid=711-127632-2357-0&ssspo=meql5djjqne&sssrc=2349624&ssuid=b_r4gulfrre&var=&widget_ver=artemis&media=COPY > >>> > > >>> >Currently I only get the firmware version in the monitor. > >>> > > >>> >On Sun, 29 Jan 2023, 21:16 Paul Bayes, ***@***.***> wrote: > >>> > > >>> >> Thanks for your help. I'll give it a go later this week. > >>> >> > >>> >> On Sun, 29 Jan 2023, 19:42 Peter Price, ***@***.***> wrote: > >>> >> > >>> >>> This is the pinout for the Leonardo I’m referring to and the > >E07 > >>> >radio > >>> >>> module > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> You need to connect the following > >>> >>> > >>> >>> > >>> >>> > >>> >>> Leonardo E07 > >>> >>> > >>> >>> D0/RX 14 > >>> >>> > >>> >>> D1/TX 15 > >>> >>> > >>> >>> 3V3 9 > >>> >>> > >>> >>> GND 12 > >>> >>> > >>> >>> D10/PB6/SS 19 > >>> >>> > >>> >>> > >>> >>> > >>> >>> And from the ICSP header (check online for ICSP pinout) > >>> >>> > >>> >>> MOSI 17 > >>> >>> > >>> >>> MISO 16 > >>> >>> > >>> >>> SCK 18 > >>> >>> > >>> >>> > >>> >>> > >>> >>> Some of the E07 pins are probably available elsewhere on the > >dev > >>> >card. > >>> >>> > >>> >>> > >>> >>> > >>> >>> Don’t forget you need to make sure the STM8 doesn’t try to > >access > >>> >the E07 > >>> >>> at the same time as the Leonardo > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> From: pdbayes ***@***.*** > >>> >>> Sent: 29 January 2023 17:16 > >>> >>> To: ghoti57/evofw3 ***@***.***> > >>> >>> Cc: Peter Price ***@***.***>; Comment ***@***.***> > >>> >>> Subject: Re: [ghoti57/evofw3] STM8 (Issue #35) > >>> >>> > >>> >>> > >>> >>> > >>> >>> Hi. Got my Leonardo board, serial monitor reports evofw3 0.7.1. > >>> >>> Can you let me know the connections please. > >>> >>> Thank you > >>> >>> > >>> >>> > >>> >>> > >>> >>> On Sat, 28 Jan 2023, 19:18 Paul Bayes, ***@***.*** > >>> ><mailto:***@***.***> > >>> >>> > wrote: > >>> >>> > >>> >>> > Thanks. I've ordered a Leonardo as I have a prototype shield > >in > >>> >this > >>> >>> > format, which might help keep things tidy. > >>> >>> > > >>> >>> > On Sat, 28 Jan 2023, 18:06 Peter Price, ***@***.*** > >>> ><mailto:***@***.***> > >>> >>> > wrote: > >>> >>> > > >>> >>> >> You want something with an atmega32u4 processor. This will > >have > >>> >a > >>> >>> direct > >>> >>> >> usb interface to the host (no driver required) and leaves the > >HW > >>> >UART > >>> >>> free > >>> >>> >> to connect to the CC1101. > >>> >>> >> > >>> >>> >> Avoid atmega328 based devices. > >>> >>> >> > >>> >>> >> When you have it let me know exactly what you have and I'll > >tell > >>> >you > >>> >>> the > >>> >>> >> connections you need. > >>> >>> >> > >>> >>> >> ⁣Get BlueMail for Android ​ > >>> >>> >> > >>> >>> >> On 28 Jan 2023, 16:08, at 16:08, pdbayes ***@***.*** > >>> ><mailto:***@***.***> > >>> >>> > wrote: > >>> >>> >> >Last question I promise. I have a different recover now with > >no > >>> >MCU. > >>> >>> >> >Which > >>> >>> >> >MCU have you found works best. I have an old cloned Nano but > >It > >>> >won't > >>> >>> >> >load > >>> >>> >> >the sketch. I think it has a Chinese rip off usb chip that's > >not > >>> >great > >>> >>> >> >and > >>> >>> >> >that is causing issues. Would the latest Nano be a good > >choice. > >>> >>> >> > > >>> >>> >> >On Fri, 27 Jan 2023, 06:57 Paul Bayes, ***@***.*** > >>> ><mailto:***@***.***> > >>> >>> > wrote: > >>> >>> >> > > >>> >>> >> >> I have an Uno so should be ok. Thanks for your help > >>> >>> >> >> > >>> >>> >> >> On Thu, 26 Jan 2023, 22:06 Peter Price, ***@***.*** > >>> ><mailto:***@***.***> > >>> >>> > wrote: > >>> >>> >> >> > >>> >>> >> >>> Just thought. > >>> >>> >> >>> > >>> >>> >> >>> The power to the e7 will have to come from the Arduino. > >>> >>> >> >>> > >>> >>> >> >>> It will also be connected to the STM8 so you need to be > >sure > >>> >that > >>> >>> >> >it > >>> >>> >> >>> doesn't configure it's GOIOs in such a way that it > >>> >interferes > >>> >>> >> >>> > >>> >>> >> >>> ⁣Get BlueMail for Android ​ > >>> >>> >> >>> > >>> >>> >> >>> On 26 Jan 2023, 22:00, at 22:00, Peter Price ***@***.*** > >>> ><mailto:***@***.***> > >>> >>> > wrote: > >>> >>> >> >>> >If you have an Arduino with an atmega32u4 or a 16MHz > >>> >atmega328p > >>> >>> and > >>> >>> >> >you > >>> >>> >> >>> >connect it correctly it will work with no code changes. > >>> >>> >> >>> > > >>> >>> >> >>> >If you only have an 8MHz atmega328p it won't. > >>> >>> >> >>> > > >>> >>> >> >>> >⁣Get BlueMail for Android ​ > >>> >>> >> >>> > > >>> >>> >> >>> >On 26 Jan 2023, 20:00, at 20:00, pdbayes ***@***.*** > >>> ><mailto:***@***.***> > >>> >>> > > >>> >>> >> >>> >wrote: > >>> >>> >> >>> >>Hmmm. I wonder if I could hard wire the GDO pins from > >the > >>> >e07 > >>> >>> >> >module > >>> >>> >> >>> >to > >>> >>> >> >>> >>an > >>> >>> >> >>> >>Arduino I have spare? Will depend on what the STM8 is > >doing > >>> >on > >>> >>> >> >those > >>> >>> >> >>> >>pins > >>> >>> >> >>> >>or any intermediate components. Or maybe using software > >on > >>> >the > >>> >>> >> >STM8 > >>> >>> >> >>> >>the > >>> >>> >> >>> >>recieved data could be sent as is to an io pin. > >>> >>> >> >>> >> > >>> >>> >> >>> >>On Thu, 26 Jan 2023, 18:22 Peter Price, ***@***.*** > >>> ><mailto:***@***.***> > >>> >>> > wrote: > >>> >>> >> >>> >> > >>> >>> >> >>> >>> I think you've misunderstood about the UART in the > >>> >context of > >>> >>> >> >>> >>evofw3. > >>> >>> >> >>> >>> > >>> >>> >> >>> >>> The bitstream that comes out of the cc1101 in an > >evohome > >>> >>> >> >environment > >>> >>> >> >>> >>has > >>> >>> >> >>> >>> effectively been generated by UARTs in the Evo > >devices > >>> >>> >> >(controller, > >>> >>> >> >>> >>rad > >>> >>> >> >>> >>> stats, thermostats etc) > >>> >>> >> >>> >>> > >>> >>> >> >>> >>> This means you need a UART interface in the STM8 > >facing > >>> >the > >>> >>> >> >CC1101. > >>> >>> >> >>> >>> > >>> >>> >> >>> >>> On your Dev board the HW UART in the STM8 is almost > >>> >certainly > >>> >>> >> >>> >>connected to > >>> >>> >> >>> >>> the USB connector on the board. > >>> >>> >> >>> >>> > >>> >>> >> >>> >>> This means the connection to GDO0 and GD02 of the > >CC1101 > >>> >will > >>> >>> >> >be > >>> >>> >> >>> >>using two > >>> >>> >> >>> >>> ordinary GPIO signals. That means you have to > >implement a > >>> >SW > >>> >>> >> >UART > >>> >>> >> >>> >in > >>> >>> >> >>> >>the > >>> >>> >> >>> >>> STM8 to decode the bitstream. You have to be able to > >>> >>> >> >synchronise > >>> >>> >> >>> >>with the > >>> >>> >> >>> >>> stop/start bits in the bitstream so that you can > >identify > >>> >and > >>> >>> >> >>> >extract > >>> >>> >> >>> >>the > >>> >>> >> >>> >>> real data. > >>> >>> >> >>> >>> > >>> >>> >> >>> >>> You are not dealing with a synchronous system. It's > >>> >>> >> >asynchronous > >>> >>> >> >>> >>because > >>> >>> >> >>> >>> all the devices have their own clock and they're all > >>> >slightly > >>> >>> >> >>> >>different. > >>> >>> >> >>> >>> > >>> >>> >> >>> >>> You're dealing with a bit stream at 38400 baud with > >>> >significant > >>> >>> >> >>> >>jitter > >>> >>> >> >>> >>> generated by some of the devices you are listening > >to. > >>> >>> >> >>> >>> > >>> >>> >> >>> >>> I very much doubt that the example software will get > >>> >anywhere > >>> >>> >> >near > >>> >>> >> >>> >>> extracting the data you need. > >>> >>> >> >>> >>> > >>> >>> >> >>> >>> > >>> >>> >> >>> >>> > >>> >>> >> >>> >>> ⁣Get BlueMail for Android ​ > >>> >>> >> >>> >>> > >>> >>> >> >>> >>> On 26 Jan 2023, 15:04, at 15:04, pdbayes ***@***.*** > >>> ><mailto:***@***.***> > >>> >>> > wrote: > >>> >>> >> >>> >>> >Thanks for the advice. > >>> >>> >> >>> >>> >The dev board is this: > >>> >>> >> >>> >>> > >>https://www.ebyte.com/en/product-view-news.html?id=1691 > >>> >>> >> >>> >>> >All the UART side of things should be handled and I > >was > >>> >hoping > >>> >>> >> >I > >>> >>> >> >>> >>would > >>> >>> >> >>> >>> >just > >>> >>> >> >>> >>> >have a stream of bits to deal with on the pi/pc. > >They > >>> >say it > >>> >>> >> >comes > >>> >>> >> >>> >>> >with > >>> >>> >> >>> >>> >example software to do this but it is within a > >>> >commercial IDE > >>> >>> >> >you > >>> >>> >> >>> >>have > >>> >>> >> >>> >>> >to > >>> >>> >> >>> >>> >pay for. It has a free trial so hopefully that will > >give > >>> >me > >>> >>> >> >enough > >>> >>> >> >>> >>time > >>> >>> >> >>> >>> >to > >>> >>> >> >>> >>> >get it working. > >>> >>> >> >>> >>> > > >>> >>> >> >>> >>> >On Thu, 26 Jan 2023 at 14:32, Peter Price > >***@***.*** > >>> ><mailto:***@***.***> > >>> >>> > wrote: > >>> >>> >> >>> >>> > > >>> >>> >> >>> >>> >> Good luck with that :-) > >>> >>> >> >>> >>> >> > >>> >>> >> >>> >>> >> The code has a lot of atmega specific code for > >the > >>> >hardware > >>> >>> >> >>> >>> >interface. > >>> >>> >> >>> >>> >> Because of the overhead the code doesn't use the > >>> >Arduino IO > >>> >>> >> >>> >>functions > >>> >>> >> >>> >>> >but > >>> >>> >> >>> >>> >> drives the GPIO pins directly via the registers. > >>> >>> >> >>> >>> >> > >>> >>> >> >>> >>> >> TX uses the SPI interface to fill the cc1101 TX > >fifo, > >>> >but, > >>> >>> >> >>> >because > >>> >>> >> >>> >>of > >>> >>> >> >>> >>> >the > >>> >>> >> >>> >>> >> jitter on the incoming signals from the other > >devices, > >>> >you > >>> >>> >> >can't > >>> >>> >> >>> >>use > >>> >>> >> >>> >>> >the > >>> >>> >> >>> >>> >> cc1101 rx fifo to capture the data because it > >assumes > >>> >>> >> >everything > >>> >>> >> >>> >>is > >>> >>> >> >>> >>> >> synchronous. > >>> >>> >> >>> >>> >> > >>> >>> >> >>> >>> >> If you try a port then I suggest you get the SPI > >>> >interface > >>> >>> to > >>> >>> >> >the > >>> >>> >> >>> >>> >CC1101 > >>> >>> >> >>> >>> >> working first and then the HW UART interface > >between > >>> >the STM > >>> >>> >> >and > >>> >>> >> >>> >>the > >>> >>> >> >>> >>> >> CC1101. This is just an ISR triggered by the UART > >that > >>> >reads > >>> >>> >> >the > >>> >>> >> >>> >>UART > >>> >>> >> >>> >>> >RX > >>> >>> >> >>> >>> >> data into a buffer. > >>> >>> >> >>> >>> >> > >>> >>> >> >>> >>> >> If the STM hasn't got a HW UART available then > >you'll > >>> >need > >>> >>> to > >>> >>> >> >be > >>> >>> >> >>> >>good > >>> >>> >> >>> >>> >at > >>> >>> >> >>> >>> >> coding. I suspect the STM8 HW UART has been > >connected > >>> >to the > >>> >>> >> >host > >>> >>> >> >>> >>> >USB > >>> >>> >> >>> >>> >> interface so this is going to be the case. > >>> >>> >> >>> >>> >> > >>> >>> >> >>> >>> >> The atmega328p SW UART code uses a HW interrupt > >to > >>> >capture > >>> >>> >> >the > >>> >>> >> >>> >>timing > >>> >>> >> >>> >>> >of > >>> >>> >> >>> >>> >> the signal edges and then a SW trap to process > >the > >>> >captured > >>> >>> >> >data > >>> >>> >> >>> >>> >edges to > >>> >>> >> >>> >>> >> generate an RX byte. This is very processor heavy > >and > >>> >every > >>> >>> >> >cycle > >>> >>> >> >>> >>is > >>> >>> >> >>> >>> >> critical to keep up with the data when it arrives. > >The > >>> >SW > >>> >>> >> >UART > >>> >>> >> >>> >>won't > >>> >>> >> >>> >>> >work > >>> >>> >> >>> >>> >> on an atmega clocked at less than 16MHz because > >there > >>> >aren't > >>> >>> >> >>> >>enough > >>> >>> >> >>> >>> >> instruction cycles available. > >>> >>> >> >>> >>> >> > >>> >>> >> >>> >>> >> The SW UART code is not as good at RXing radio > >>> >messages as > >>> >>> >> >the HW > >>> >>> >> >>> >>> >UART > >>> >>> >> >>> >>> >> code. > >>> >>> >> >>> >>> >> > >>> >>> >> >>> >>> >> Using a simple USB logic analyser ( e.g. > >>> >>> >> >>> >>> >> > >>> >>> >> >>> >>> > > >>> >>> >> >>> >>> > >>> >>> >> >>> >> > >>> >>> >> >>> > >>> >>> >> > > >>> >>> >> > >>> >>> > >>> > > >>> > > > https://www.amazon.co.uk/Hobby-Components-24MHz-Analyser-1-1-16/dp/B00DAYAREW > >>> >>> >> >>> >>> ) > >>> >>> >> >>> >>> >> there are some debug lines still in the code that > >you > >>> >can > >>> >>> use > >>> >>> >> >to > >>> >>> >> >>> >>> >drive > >>> >>> >> >>> >>> >> spare GPIO pins that will show you how much > >processor > >>> >time > >>> >>> >> >you're > >>> >>> >> >>> >>> >using in > >>> >>> >> >>> >>> >> the HW and SW ISR functions. > >>> >>> >> >>> >>> >> > >>> >>> >> >>> >>> >> The frame, message and host interface code should > >>> >work > >>> >>> >> >without > >>> >>> >> >>> >>> >significant > >>> >>> >> >>> >>> >> changes. > >>> >>> >> >>> >>> >> > >>> >>> >> >>> >>> >> That's all the help I can offer since I have zero > >STM > >>> >>> >> >knowledge. > >>> >>> >> >>> >>> >> > >>> >>> >> >>> >>> >> If you don't understand what I've said above give > >up > >>> >now. > >>> >>> >> >>> >>> >> > >>> >>> >> >>> >>> >> — > >>> >>> >> >>> >>> >> Reply to this email directly, view it on GitHub > >>> >>> >> >>> >>> >> > >>> >>> >> >>> >>> > >>> >>> >> >>> > >>> >>> >> >>>>< > >>> >>> > >#35 (comment) > >>> >< > >>> >>> > >#35 (comment) > >>> >> > >>> >>> >> >, > >>> >>> >> >>> >>> >or > >>> >>> >> >>> >>> >> unsubscribe > >>> >>> >> >>> >>> >> > >>> >>> >> >>> >>> >< > >>> >>> >> >>> >>> > >>> >>> >> >>> >> > >>> >>> >> >>> > >>> >>> >> > > >>> >>> >> > >>> >>> > >>> > > >>> > > > https://github.com/notifications/unsubscribe-auth/AN4GHPSSWORQMO6CGL6XQV3WUKDJNANCNFSM6AAAAAAUHJSYXI > >>> >>> >> >>> >>> > > >>> >>> >> >>> >>> >> . > >>> >>> >> >>> >>> >> You are receiving this because you authored the > >>> >>> >> >thread.Message > >>> >>> >> >>> >>ID: > >>> >>> >> >>> >>> >> ***@***.*** <mailto:***@***.***> > > >>> >>> >> >>> >>> >> > >>> >>> >> >>> >>> > > >>> >>> >> >>> >>> > > >>> >>> >> >>> >>> >-- > >>> >>> >> >>> >>> >Reply to this email directly or view it on GitHub: > >>> >>> >> >>> >>> > >>> >>> >> > >>> > >>>>#35 (comment) > >>> >>> >> >>> >>> >You are receiving this because you commented. > >>> >>> >> >>> >>> > > >>> >>> >> >>> >>> >Message ID: ***@***.*** <mailto:***@***.***> > > >>> >>> >> >>> >>> > >>> >>> >> >>> >>> — > >>> >>> >> >>> >>> Reply to this email directly, view it on GitHub > >>> >>> >> >>> >>> > >>> >>> >> >>> > >>> >>> >> >>>< > >>> >>> > >>> > >>#35 (comment)>, > >>> >>> >> >>> >>or > >>> >>> >> >>> >>> unsubscribe > >>> >>> >> >>> >>> > >>> >>> >> >>> >>< > >>> >>> >> >>> > >>> >>> >> > > >>> >>> >> > >>> >>> > >>> > > >>> > > > https://github.com/notifications/unsubscribe-auth/AN4GHPWOTGSC3DO2F7TN4M3WUK6FHANCNFSM6AAAAAAUHJSYXI > >>> >>> >> >>> > > >>> >>> >> >>> >>> . > >>> >>> >> >>> >>> You are receiving this because you authored the > >>> >thread.Message > >>> >>> >> >ID: > >>> >>> >> >>> >>> ***@***.*** <mailto:***@***.***> > > >>> >>> >> >>> >>> > >>> >>> >> >>> >> > >>> >>> >> >>> >> > >>> >>> >> >>> >>-- > >>> >>> >> >>> >>Reply to this email directly or view it on GitHub: > >>> >>> >> >>> > >>> >>> >> > >>> > >>>>>#35 (comment) > >>> >>> >> >>> >>You are receiving this because you commented. > >>> >>> >> >>> >> > >>> >>> >> >>> >>Message ID: ***@***.*** <mailto:***@***.***> > > >>> >>> >> >>> > >>> >>> >> >>> — > >>> >>> >> >>> Reply to this email directly, view it on GitHub > >>> >>> >> >>> > >>> >>> >> > >>> > >>><#35 (comment) > >>> >>> >, > >>> >>> >> >>> or unsubscribe > >>> >>> >> >>> > >>> >>> >> >< > >>> >>> >> > >>> >>> > >>> > > >>> > > > https://github.com/notifications/unsubscribe-auth/AN4GHPWDEQVBRFCQWOYLZOLWULYNPANCNFSM6AAAAAAUHJSYXI > >>> >>> >> > > >>> >>> >> >>> . > >>> >>> >> >>> You are receiving this because you authored the > >>> >thread.Message ID: > >>> >>> >> >>> ***@***.*** <mailto:***@***.***> > > >>> >>> >> >>> > >>> >>> >> >> > >>> >>> >> > > >>> >>> >> > > >>> >>> >> >-- > >>> >>> >> >Reply to this email directly or view it on GitHub: > >>> >>> >> > >>> > >>>#35 (comment) > >>> >>> >> >You are receiving this because you commented. > >>> >>> >> > > >>> >>> >> >Message ID: ***@***.*** <mailto:***@***.***> > > >>> >>> >> > >>> >>> >> — > >>> >>> >> Reply to this email directly, view it on GitHub > >>> >>> >> > >>> > >><#35 (comment)>, > >>> >>> >> or unsubscribe > >>> >>> >> < > >>> >>> > >>> > > >>> > > > https://github.com/notifications/unsubscribe-auth/AN4GHPWNBGQWDHVC25NK6GLWUVN2ZANCNFSM6AAAAAAUHJSYXI > >>> >>> > > >>> >>> >> . > >>> >>> >> You are receiving this because you authored the > >thread.Message > >>> >ID: > >>> >>> >> ***@***.*** <mailto:***@***.***> > > >>> >>> >> > >>> >>> > > >>> >>> > >>> >>> > >>> >>> > >>> >>> — > >>> >>> Reply to this email directly, view it on GitHub < > >>> >>> > >#35 (comment)> > >>> >, > >>> >>> or unsubscribe < > >>> >>> > >>> > > >>> > > > https://github.com/notifications/unsubscribe-auth/AIRU2WZ6QZ2JTH4S7JDX2OLWU2QWFANCNFSM6AAAAAAUHJSYXI > >>> > > >>> >>> . > >>> >>> You are receiving this because you commented. < > >>> >>> > >>> > > >>> > > > https://github.com/notifications/beacon/AIRU2W6ZSCHUD2NWHFVREOTWU2QWFA5CNFSM6AAAAAAUHJSYXKWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTST5ANTO.gif > >>> > > >>> >>> Message ID: < ***@***.***> ***@***.***> > >>> >>> > >>> >>> — > >>> >>> Reply to this email directly, view it on GitHub > >>> >>> > >>> > >><#35 (comment)>, > >>> >>> or unsubscribe > >>> >>> > >>> >< > >>> > > > https://github.com/notifications/unsubscribe-auth/AN4GHPWVQWX2H6DMZ7ZWXZTWU3B2XANCNFSM6AAAAAAUHJSYXI > >>> > > >>> >>> . > >>> >>> You are receiving this because you authored the thread.Message > >ID: > >>> >>> ***@***.***> > >>> >>> > >>> >> > >>> > > >>> > > >>> >-- > >>> >Reply to this email directly or view it on GitHub: > >>> > >>#35 (comment) > >>> >You are receiving this because you commented. > >>> > > >>> >Message ID: ***@***.***> > >>> > >>> — > >>> Reply to this email directly, view it on GitHub > >>> > ><#35 (comment)>, > >>> or unsubscribe > >>> > >< > https://github.com/notifications/unsubscribe-auth/AN4GHPQ66E3C37NVCBNLY4LWVGGSVANCNFSM6AAAAAAUHJSYXI > > > >>> . > >>> You are receiving this because you authored the thread.Message ID: > >>> ***@***.***> > >>> > >> > > > > > >-- > >Reply to this email directly or view it on GitHub: > >#35 (comment) > >You are receiving this because you commented. > > > >Message ID: ***@***.***> > > — > Reply to this email directly, view it on GitHub > <#35 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AN4GHPTQPA4ZFLA47AKROBTWVKRLRANCNFSM6AAAAAAUHJSYXI> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

On 5 Feb 2023, 09:44, at 09:44, pdbayes ***@***.***> wrote: Well, this turned into a bit of a saga on eBay. If you are interested I can fill you in. In the end I decided to get one of these as trying to do it on the cheap actually ended up costing more in time and money. https://schlauhaus.biz/en/product/nanocul-868-kit/ Now I need to work out the best way to get the info into node red so I can then save it in Influxdb and make a web front end for it. On Wed, 1 Feb 2023, 18:28 Paul Bayes, ***@***.***> wrote: > I agree. See what he says. > > On Wed, 1 Feb 2023, 18:11 Peter Price, ***@***.***> wrote: > >> Evofw3 configured the card for 868MHz. >> >> But t the point is the antenna is not optimised for that frequency. >> >> The pictures on the site show the card is printed with 433MHz >> >> When I was looking, all the modules that looked like this appeared to be >> 433MHz >> >> >> >> ⁣Get BlueMail for Android ​ >> >> On 1 Feb 2023, 08:20, at 08:20, pdbayes ***@***.***> wrote: >> >This is the sellers response, I have pointed out that you need a >> >different >> >design for the external components for the higher frequency band and >> >also >> >that the antenna should be half the length. >> >New message from: hol-5376 >> >< >> https://www.ebay.co.uk/ulk/usr/hol-5376?mkevt=1&mkpid=0&emsid=e11051.m44.l1181&mkcid=7&ch=osgood&euid=d67b2f6f16d4484780ed2f0a8fed1e3e&bu=45544770190&osub=-1%7E1&crd=20230131165028&segname=11051 >> > >> > (18[image: YELLOW_STAR Star]) >> >< >> https://www.ebay.co.uk/fdbk/feedback_profile/hol-5376?mkevt=1&mkpid=0&emsid=e11051.m44.l1183&mkcid=7&ch=osgood&euid=d67b2f6f16d4484780ed2f0a8fed1e3e&bu=45544770190&osub=-1%7E1&crd=20230131165028&segname=11051 >> > >> > >> >Are you using Arduino to program it? >> > >> >If so what library? >> >I've used the Elechouse library, and then you can use the .setMHZ() >> >function to set the frequency >> > >> >You can enter any number in the range 779 - 928 MHz >> > >> >You can have a look here for some examples, and a good guide: >> >https://github.com/LSatan/SmartRC-CC1101-Driver-Lib >> > >> > >> >On Tue, 31 Jan 2023, 22:48 Paul Bayes, ***@***.***> wrote: >> > >> >> That's a good point. It doesn't say which of the frequencies it's >> >> configured for. >> >> I'll mail him. Pain in the bum. >> >> >> >> On Tue, 31 Jan 2023, 22:26 Peter Price, ***@***.***> wrote: >> >> >> >>> While the cc1101 will operate in all those frequency bands the >> >circuit >> >>> between the chip and antenna is different. >> >>> >> >>> It's possible that the module you've bought is configured for 433 >> >MHz. >> >>> It's very unlikely that you can buy a module that will work at all >> >>> frequencies. >> >>> >> >>> You should be able to tell by looking closely at the layout of the >> >>> components and comparing it to the TI documentation for the CC1101. >> >>> >> >>> ⁣Get BlueMail for Android ​ >> >>> >> >>> On 31 Jan 2023, 21:04, at 21:04, pdbayes ***@***.***> wrote: >> >>> >Hi >> >>> > >> >>> >I assume if wired correctly and firmware loaded, I should see some >> >data >> >>> >in >> >>> >the serial monitor? >> >>> >I got one of these in the end and cross referenced your connection >> >>> >instruction with the E07. >> >>> > >> >>> >> > >> https://www.ebay.co.uk/itm/394035907922?mkcid=16&mkevt=1&mkrid=711-127632-2357-0&ssspo=meql5djjqne&sssrc=2349624&ssuid=b_r4gulfrre&var=&widget_ver=artemis&media=COPY >> >>> > >> >>> >Currently I only get the firmware version in the monitor. >> >>> > >> >>> >On Sun, 29 Jan 2023, 21:16 Paul Bayes, ***@***.***> wrote: >> >>> > >> >>> >> Thanks for your help. I'll give it a go later this week. >> >>> >> >> >>> >> On Sun, 29 Jan 2023, 19:42 Peter Price, ***@***.***> wrote: >> >>> >> >> >>> >>> This is the pinout for the Leonardo I’m referring to and the >> >E07 >> >>> >radio >> >>> >>> module >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> You need to connect the following >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> Leonardo E07 >> >>> >>> >> >>> >>> D0/RX 14 >> >>> >>> >> >>> >>> D1/TX 15 >> >>> >>> >> >>> >>> 3V3 9 >> >>> >>> >> >>> >>> GND 12 >> >>> >>> >> >>> >>> D10/PB6/SS 19 >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> And from the ICSP header (check online for ICSP pinout) >> >>> >>> >> >>> >>> MOSI 17 >> >>> >>> >> >>> >>> MISO 16 >> >>> >>> >> >>> >>> SCK 18 >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> Some of the E07 pins are probably available elsewhere on the >> >dev >> >>> >card. >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> Don’t forget you need to make sure the STM8 doesn’t try to >> >access >> >>> >the E07 >> >>> >>> at the same time as the Leonardo >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> From: pdbayes ***@***.*** >> >>> >>> Sent: 29 January 2023 17:16 >> >>> >>> To: ghoti57/evofw3 ***@***.***> >> >>> >>> Cc: Peter Price ***@***.***>; Comment ***@***.***> >> >>> >>> Subject: Re: [ghoti57/evofw3] STM8 (Issue #35) >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> Hi. Got my Leonardo board, serial monitor reports evofw3 0.7.1. >> >>> >>> Can you let me know the connections please. >> >>> >>> Thank you >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> On Sat, 28 Jan 2023, 19:18 Paul Bayes, ***@***.*** >> >>> ><mailto:***@***.***> >> >>> >>> > wrote: >> >>> >>> >> >>> >>> > Thanks. I've ordered a Leonardo as I have a prototype shield >> >in >> >>> >this >> >>> >>> > format, which might help keep things tidy. >> >>> >>> > >> >>> >>> > On Sat, 28 Jan 2023, 18:06 Peter Price, ***@***.*** >> >>> ><mailto:***@***.***> >> >>> >>> > wrote: >> >>> >>> > >> >>> >>> >> You want something with an atmega32u4 processor. This will >> >have >> >>> >a >> >>> >>> direct >> >>> >>> >> usb interface to the host (no driver required) and leaves the >> >HW >> >>> >UART >> >>> >>> free >> >>> >>> >> to connect to the CC1101. >> >>> >>> >> >> >>> >>> >> Avoid atmega328 based devices. >> >>> >>> >> >> >>> >>> >> When you have it let me know exactly what you have and I'll >> >tell >> >>> >you >> >>> >>> the >> >>> >>> >> connections you need. >> >>> >>> >> >> >>> >>> >> ⁣Get BlueMail for Android ​ >> >>> >>> >> >> >>> >>> >> On 28 Jan 2023, 16:08, at 16:08, pdbayes ***@***.*** >> >>> ><mailto:***@***.***> >> >>> >>> > wrote: >> >>> >>> >> >Last question I promise. I have a different recover now with >> >no >> >>> >MCU. >> >>> >>> >> >Which >> >>> >>> >> >MCU have you found works best. I have an old cloned Nano but >> >It >> >>> >won't >> >>> >>> >> >load >> >>> >>> >> >the sketch. I think it has a Chinese rip off usb chip that's >> >not >> >>> >great >> >>> >>> >> >and >> >>> >>> >> >that is causing issues. Would the latest Nano be a good >> >choice. >> >>> >>> >> > >> >>> >>> >> >On Fri, 27 Jan 2023, 06:57 Paul Bayes, ***@***.*** >> >>> ><mailto:***@***.***> >> >>> >>> > wrote: >> >>> >>> >> > >> >>> >>> >> >> I have an Uno so should be ok. Thanks for your help >> >>> >>> >> >> >> >>> >>> >> >> On Thu, 26 Jan 2023, 22:06 Peter Price, ***@***.*** >> >>> ><mailto:***@***.***> >> >>> >>> > wrote: >> >>> >>> >> >> >> >>> >>> >> >>> Just thought. >> >>> >>> >> >>> >> >>> >>> >> >>> The power to the e7 will have to come from the Arduino. >> >>> >>> >> >>> >> >>> >>> >> >>> It will also be connected to the STM8 so you need to be >> >sure >> >>> >that >> >>> >>> >> >it >> >>> >>> >> >>> doesn't configure it's GOIOs in such a way that it >> >>> >interferes >> >>> >>> >> >>> >> >>> >>> >> >>> ⁣Get BlueMail for Android ​ >> >>> >>> >> >>> >> >>> >>> >> >>> On 26 Jan 2023, 22:00, at 22:00, Peter Price ***@***.*** >> >>> ><mailto:***@***.***> >> >>> >>> > wrote: >> >>> >>> >> >>> >If you have an Arduino with an atmega32u4 or a 16MHz >> >>> >atmega328p >> >>> >>> and >> >>> >>> >> >you >> >>> >>> >> >>> >connect it correctly it will work with no code changes. >> >>> >>> >> >>> > >> >>> >>> >> >>> >If you only have an 8MHz atmega328p it won't. >> >>> >>> >> >>> > >> >>> >>> >> >>> >⁣Get BlueMail for Android ​ >> >>> >>> >> >>> > >> >>> >>> >> >>> >On 26 Jan 2023, 20:00, at 20:00, pdbayes ***@***.*** >> >>> ><mailto:***@***.***> >> >>> >>> > >> >>> >>> >> >>> >wrote: >> >>> >>> >> >>> >>Hmmm. I wonder if I could hard wire the GDO pins from >> >the >> >>> >e07 >> >>> >>> >> >module >> >>> >>> >> >>> >to >> >>> >>> >> >>> >>an >> >>> >>> >> >>> >>Arduino I have spare? Will depend on what the STM8 is >> >doing >> >>> >on >> >>> >>> >> >those >> >>> >>> >> >>> >>pins >> >>> >>> >> >>> >>or any intermediate components. Or maybe using software >> >on >> >>> >the >> >>> >>> >> >STM8 >> >>> >>> >> >>> >>the >> >>> >>> >> >>> >>recieved data could be sent as is to an io pin. >> >>> >>> >> >>> >> >> >>> >>> >> >>> >>On Thu, 26 Jan 2023, 18:22 Peter Price, ***@***.*** >> >>> ><mailto:***@***.***> >> >>> >>> > wrote: >> >>> >>> >> >>> >> >> >>> >>> >> >>> >>> I think you've misunderstood about the UART in the >> >>> >context of >> >>> >>> >> >>> >>evofw3. >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> The bitstream that comes out of the cc1101 in an >> >evohome >> >>> >>> >> >environment >> >>> >>> >> >>> >>has >> >>> >>> >> >>> >>> effectively been generated by UARTs in the Evo >> >devices >> >>> >>> >> >(controller, >> >>> >>> >> >>> >>rad >> >>> >>> >> >>> >>> stats, thermostats etc) >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> This means you need a UART interface in the STM8 >> >facing >> >>> >the >> >>> >>> >> >CC1101. >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> On your Dev board the HW UART in the STM8 is almost >> >>> >certainly >> >>> >>> >> >>> >>connected to >> >>> >>> >> >>> >>> the USB connector on the board. >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> This means the connection to GDO0 and GD02 of the >> >CC1101 >> >>> >will >> >>> >>> >> >be >> >>> >>> >> >>> >>using two >> >>> >>> >> >>> >>> ordinary GPIO signals. That means you have to >> >implement a >> >>> >SW >> >>> >>> >> >UART >> >>> >>> >> >>> >in >> >>> >>> >> >>> >>the >> >>> >>> >> >>> >>> STM8 to decode the bitstream. You have to be able to >> >>> >>> >> >synchronise >> >>> >>> >> >>> >>with the >> >>> >>> >> >>> >>> stop/start bits in the bitstream so that you can >> >identify >> >>> >and >> >>> >>> >> >>> >extract >> >>> >>> >> >>> >>the >> >>> >>> >> >>> >>> real data. >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> You are not dealing with a synchronous system. It's >> >>> >>> >> >asynchronous >> >>> >>> >> >>> >>because >> >>> >>> >> >>> >>> all the devices have their own clock and they're all >> >>> >slightly >> >>> >>> >> >>> >>different. >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> You're dealing with a bit stream at 38400 baud with >> >>> >significant >> >>> >>> >> >>> >>jitter >> >>> >>> >> >>> >>> generated by some of the devices you are listening >> >to. >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> I very much doubt that the example software will get >> >>> >anywhere >> >>> >>> >> >near >> >>> >>> >> >>> >>> extracting the data you need. >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> ⁣Get BlueMail for Android ​ >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> On 26 Jan 2023, 15:04, at 15:04, pdbayes ***@***.*** >> >>> ><mailto:***@***.***> >> >>> >>> > wrote: >> >>> >>> >> >>> >>> >Thanks for the advice. >> >>> >>> >> >>> >>> >The dev board is this: >> >>> >>> >> >>> >>> >> >>https://www.ebyte.com/en/product-view-news.html?id=1691 >> >>> >>> >> >>> >>> >All the UART side of things should be handled and I >> >was >> >>> >hoping >> >>> >>> >> >I >> >>> >>> >> >>> >>would >> >>> >>> >> >>> >>> >just >> >>> >>> >> >>> >>> >have a stream of bits to deal with on the pi/pc. >> >They >> >>> >say it >> >>> >>> >> >comes >> >>> >>> >> >>> >>> >with >> >>> >>> >> >>> >>> >example software to do this but it is within a >> >>> >commercial IDE >> >>> >>> >> >you >> >>> >>> >> >>> >>have >> >>> >>> >> >>> >>> >to >> >>> >>> >> >>> >>> >pay for. It has a free trial so hopefully that will >> >give >> >>> >me >> >>> >>> >> >enough >> >>> >>> >> >>> >>time >> >>> >>> >> >>> >>> >to >> >>> >>> >> >>> >>> >get it working. >> >>> >>> >> >>> >>> > >> >>> >>> >> >>> >>> >On Thu, 26 Jan 2023 at 14:32, Peter Price >> >***@***.*** >> >>> ><mailto:***@***.***> >> >>> >>> > wrote: >> >>> >>> >> >>> >>> > >> >>> >>> >> >>> >>> >> Good luck with that :-) >> >>> >>> >> >>> >>> >> >> >>> >>> >> >>> >>> >> The code has a lot of atmega specific code for >> >the >> >>> >hardware >> >>> >>> >> >>> >>> >interface. >> >>> >>> >> >>> >>> >> Because of the overhead the code doesn't use the >> >>> >Arduino IO >> >>> >>> >> >>> >>functions >> >>> >>> >> >>> >>> >but >> >>> >>> >> >>> >>> >> drives the GPIO pins directly via the registers. >> >>> >>> >> >>> >>> >> >> >>> >>> >> >>> >>> >> TX uses the SPI interface to fill the cc1101 TX >> >fifo, >> >>> >but, >> >>> >>> >> >>> >because >> >>> >>> >> >>> >>of >> >>> >>> >> >>> >>> >the >> >>> >>> >> >>> >>> >> jitter on the incoming signals from the other >> >devices, >> >>> >you >> >>> >>> >> >can't >> >>> >>> >> >>> >>use >> >>> >>> >> >>> >>> >the >> >>> >>> >> >>> >>> >> cc1101 rx fifo to capture the data because it >> >assumes >> >>> >>> >> >everything >> >>> >>> >> >>> >>is >> >>> >>> >> >>> >>> >> synchronous. >> >>> >>> >> >>> >>> >> >> >>> >>> >> >>> >>> >> If you try a port then I suggest you get the SPI >> >>> >interface >> >>> >>> to >> >>> >>> >> >the >> >>> >>> >> >>> >>> >CC1101 >> >>> >>> >> >>> >>> >> working first and then the HW UART interface >> >between >> >>> >the STM >> >>> >>> >> >and >> >>> >>> >> >>> >>the >> >>> >>> >> >>> >>> >> CC1101. This is just an ISR triggered by the UART >> >that >> >>> >reads >> >>> >>> >> >the >> >>> >>> >> >>> >>UART >> >>> >>> >> >>> >>> >RX >> >>> >>> >> >>> >>> >> data into a buffer. >> >>> >>> >> >>> >>> >> >> >>> >>> >> >>> >>> >> If the STM hasn't got a HW UART available then >> >you'll >> >>> >need >> >>> >>> to >> >>> >>> >> >be >> >>> >>> >> >>> >>good >> >>> >>> >> >>> >>> >at >> >>> >>> >> >>> >>> >> coding. I suspect the STM8 HW UART has been >> >connected >> >>> >to the >> >>> >>> >> >host >> >>> >>> >> >>> >>> >USB >> >>> >>> >> >>> >>> >> interface so this is going to be the case. >> >>> >>> >> >>> >>> >> >> >>> >>> >> >>> >>> >> The atmega328p SW UART code uses a HW interrupt >> >to >> >>> >capture >> >>> >>> >> >the >> >>> >>> >> >>> >>timing >> >>> >>> >> >>> >>> >of >> >>> >>> >> >>> >>> >> the signal edges and then a SW trap to process >> >the >> >>> >captured >> >>> >>> >> >data >> >>> >>> >> >>> >>> >edges to >> >>> >>> >> >>> >>> >> generate an RX byte. This is very processor heavy >> >and >> >>> >every >> >>> >>> >> >cycle >> >>> >>> >> >>> >>is >> >>> >>> >> >>> >>> >> critical to keep up with the data when it arrives. >> >The >> >>> >SW >> >>> >>> >> >UART >> >>> >>> >> >>> >>won't >> >>> >>> >> >>> >>> >work >> >>> >>> >> >>> >>> >> on an atmega clocked at less than 16MHz because >> >there >> >>> >aren't >> >>> >>> >> >>> >>enough >> >>> >>> >> >>> >>> >> instruction cycles available. >> >>> >>> >> >>> >>> >> >> >>> >>> >> >>> >>> >> The SW UART code is not as good at RXing radio >> >>> >messages as >> >>> >>> >> >the HW >> >>> >>> >> >>> >>> >UART >> >>> >>> >> >>> >>> >> code. >> >>> >>> >> >>> >>> >> >> >>> >>> >> >>> >>> >> Using a simple USB logic analyser ( e.g. >> >>> >>> >> >>> >>> >> >> >>> >>> >> >>> >>> > >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >> >> >>> >>> >> >>> >> >>> >>> >> > >> >>> >>> >> >> >>> >>> >> >>> > >> >>> >> > >> https://www.amazon.co.uk/Hobby-Components-24MHz-Analyser-1-1-16/dp/B00DAYAREW >> >>> >>> >> >>> >>> ) >> >>> >>> >> >>> >>> >> there are some debug lines still in the code that >> >you >> >>> >can >> >>> >>> use >> >>> >>> >> >to >> >>> >>> >> >>> >>> >drive >> >>> >>> >> >>> >>> >> spare GPIO pins that will show you how much >> >processor >> >>> >time >> >>> >>> >> >you're >> >>> >>> >> >>> >>> >using in >> >>> >>> >> >>> >>> >> the HW and SW ISR functions. >> >>> >>> >> >>> >>> >> >> >>> >>> >> >>> >>> >> The frame, message and host interface code should >> >>> >work >> >>> >>> >> >without >> >>> >>> >> >>> >>> >significant >> >>> >>> >> >>> >>> >> changes. >> >>> >>> >> >>> >>> >> >> >>> >>> >> >>> >>> >> That's all the help I can offer since I have zero >> >STM >> >>> >>> >> >knowledge. >> >>> >>> >> >>> >>> >> >> >>> >>> >> >>> >>> >> If you don't understand what I've said above give >> >up >> >>> >now. >> >>> >>> >> >>> >>> >> >> >>> >>> >> >>> >>> >> — >> >>> >>> >> >>> >>> >> Reply to this email directly, view it on GitHub >> >>> >>> >> >>> >>> >> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >> >>> >>> >> >>>>< >> >>> >>> >> >#35 (comment) >> >>> >< >> >>> >>> >> >#35 (comment) >> >>> >> >> >>> >>> >> >, >> >>> >>> >> >>> >>> >or >> >>> >>> >> >>> >>> >> unsubscribe >> >>> >>> >> >>> >>> >> >> >>> >>> >> >>> >>> >< >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >> >> >>> >>> >> >>> >> >>> >>> >> > >> >>> >>> >> >> >>> >>> >> >>> > >> >>> >> > >> https://github.com/notifications/unsubscribe-auth/AN4GHPSSWORQMO6CGL6XQV3WUKDJNANCNFSM6AAAAAAUHJSYXI >> >>> >>> >> >>> >>> > >> >>> >>> >> >>> >>> >> . >> >>> >>> >> >>> >>> >> You are receiving this because you authored the >> >>> >>> >> >thread.Message >> >>> >>> >> >>> >>ID: >> >>> >>> >> >>> >>> >> ***@***.*** <mailto:***@***.***> > >> >>> >>> >> >>> >>> >> >> >>> >>> >> >>> >>> > >> >>> >>> >> >>> >>> > >> >>> >>> >> >>> >>> >-- >> >>> >>> >> >>> >>> >Reply to this email directly or view it on GitHub: >> >>> >>> >> >>> >>> >> >>> >>> >> >> >>> >> >>>>#35 (comment) >> >>> >>> >> >>> >>> >You are receiving this because you commented. >> >>> >>> >> >>> >>> > >> >>> >>> >> >>> >>> >Message ID: ***@***.*** <mailto:***@***.***> > >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> — >> >>> >>> >> >>> >>> Reply to this email directly, view it on GitHub >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >> >>> >>> >> >>>< >> >>> >>> >> >>> >> >>#35 (comment)>, >> >>> >>> >> >>> >>or >> >>> >>> >> >>> >>> unsubscribe >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>< >> >>> >>> >> >>> >> >>> >>> >> > >> >>> >>> >> >> >>> >>> >> >>> > >> >>> >> > >> https://github.com/notifications/unsubscribe-auth/AN4GHPWOTGSC3DO2F7TN4M3WUK6FHANCNFSM6AAAAAAUHJSYXI >> >>> >>> >> >>> > >> >>> >>> >> >>> >>> . >> >>> >>> >> >>> >>> You are receiving this because you authored the >> >>> >thread.Message >> >>> >>> >> >ID: >> >>> >>> >> >>> >>> ***@***.*** <mailto:***@***.***> > >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >> >> >>> >>> >> >>> >> >> >>> >>> >> >>> >>-- >> >>> >>> >> >>> >>Reply to this email directly or view it on GitHub: >> >>> >>> >> >>> >> >>> >>> >> >> >>> >> >>>>>#35 (comment) >> >>> >>> >> >>> >>You are receiving this because you commented. >> >>> >>> >> >>> >> >> >>> >>> >> >>> >>Message ID: ***@***.*** <mailto:***@***.***> > >> >>> >>> >> >>> >> >>> >>> >> >>> — >> >>> >>> >> >>> Reply to this email directly, view it on GitHub >> >>> >>> >> >>> >> >>> >>> >> >> >>> >> >>><#35 (comment) >> >>> >>> >, >> >>> >>> >> >>> or unsubscribe >> >>> >>> >> >>> >> >>> >>> >> >< >> >>> >>> >> >> >>> >>> >> >>> > >> >>> >> > >> https://github.com/notifications/unsubscribe-auth/AN4GHPWDEQVBRFCQWOYLZOLWULYNPANCNFSM6AAAAAAUHJSYXI >> >>> >>> >> > >> >>> >>> >> >>> . >> >>> >>> >> >>> You are receiving this because you authored the >> >>> >thread.Message ID: >> >>> >>> >> >>> ***@***.*** <mailto:***@***.***> > >> >>> >>> >> >>> >> >>> >>> >> >> >> >>> >>> >> > >> >>> >>> >> > >> >>> >>> >> >-- >> >>> >>> >> >Reply to this email directly or view it on GitHub: >> >>> >>> >> >> >>> >> >>>#35 (comment) >> >>> >>> >> >You are receiving this because you commented. >> >>> >>> >> > >> >>> >>> >> >Message ID: ***@***.*** <mailto:***@***.***> > >> >>> >>> >> >> >>> >>> >> — >> >>> >>> >> Reply to this email directly, view it on GitHub >> >>> >>> >> >> >>> >> >><#35 (comment)>, >> >>> >>> >> or unsubscribe >> >>> >>> >> < >> >>> >>> >> >>> > >> >>> >> > >> https://github.com/notifications/unsubscribe-auth/AN4GHPWNBGQWDHVC25NK6GLWUVN2ZANCNFSM6AAAAAAUHJSYXI >> >>> >>> > >> >>> >>> >> . >> >>> >>> >> You are receiving this because you authored the >> >thread.Message >> >>> >ID: >> >>> >>> >> ***@***.*** <mailto:***@***.***> > >> >>> >>> >> >> >>> >>> > >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> — >> >>> >>> Reply to this email directly, view it on GitHub < >> >>> >>> >> >#35 (comment)> >> >>> >, >> >>> >>> or unsubscribe < >> >>> >>> >> >>> > >> >>> >> > >> https://github.com/notifications/unsubscribe-auth/AIRU2WZ6QZ2JTH4S7JDX2OLWU2QWFANCNFSM6AAAAAAUHJSYXI >> >>> > >> >>> >>> . >> >>> >>> You are receiving this because you commented. < >> >>> >>> >> >>> > >> >>> >> > >> https://github.com/notifications/beacon/AIRU2W6ZSCHUD2NWHFVREOTWU2QWFA5CNFSM6AAAAAAUHJSYXKWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTST5ANTO.gif >> >>> > >> >>> >>> Message ID: < ***@***.***> ***@***.***> >> >>> >>> >> >>> >>> — >> >>> >>> Reply to this email directly, view it on GitHub >> >>> >>> >> >>> >> >><#35 (comment)>, >> >>> >>> or unsubscribe >> >>> >>> >> >>> >< >> >>> >> > >> https://github.com/notifications/unsubscribe-auth/AN4GHPWVQWX2H6DMZ7ZWXZTWU3B2XANCNFSM6AAAAAAUHJSYXI >> >>> > >> >>> >>> . >> >>> >>> You are receiving this because you authored the thread.Message >> >ID: >> >>> >>> ***@***.***> >> >>> >>> >> >>> >> >> >>> > >> >>> > >> >>> >-- >> >>> >Reply to this email directly or view it on GitHub: >> >>> >> >>#35 (comment) >> >>> >You are receiving this because you commented. >> >>> > >> >>> >Message ID: ***@***.***> >> >>> >> >>> — >> >>> Reply to this email directly, view it on GitHub >> >>> >> ><#35 (comment)>, >> >>> or unsubscribe >> >>> >> >< >> https://github.com/notifications/unsubscribe-auth/AN4GHPQ66E3C37NVCBNLY4LWVGGSVANCNFSM6AAAAAAUHJSYXI >> > >> >>> . >> >>> You are receiving this because you authored the thread.Message ID: >> >>> ***@***.***> >> >>> >> >> >> > >> > >> >-- >> >Reply to this email directly or view it on GitHub: >> >#35 (comment) >> >You are receiving this because you commented. >> > >> >Message ID: ***@***.***> >> >> — >> Reply to this email directly, view it on GitHub >> <#35 (comment)>, >> or unsubscribe >> <https://github.com/notifications/unsubscribe-auth/AN4GHPTQPA4ZFLA47AKROBTWVKRLRANCNFSM6AAAAAAUHJSYXI> >> . >> You are receiving this because you authored the thread.Message ID: >> ***@***.***> >> > -- Reply to this email directly or view it on GitHub: #35 (comment) You are receiving this because you commented. Message ID: ***@***.***>

On Sun, 5 Feb 2023, 11:08 Peter Price, ***@***.***> wrote: That's probably not the best choice of a processor board. They are listing options for usb/serial chips which means that the HW UART in the processor is being used for the host interfaces and not the radio interface. That means any attempt to extract the data from the radio is limited to SW UART code. It works but not as effectively as a HW UART. The processor is almost certainly an atmega328p. If it doesn't run at 16MHz it doesn't have enough processor cycles to run the SW UART. If you want to run evofw3 you won't be able to use the Arduino gui to update the firmware. The CUL sticks use a different bootloader. The CUL firmware claims to be able to receive evohome messages but the method it uses cannot deal with some of the variations it might encounter. ⁣Get BlueMail for Android ​ On 5 Feb 2023, 09:44, at 09:44, pdbayes ***@***.***> wrote: >Well, this turned into a bit of a saga on eBay. If you are interested I >can >fill you in. >In the end I decided to get one of these as trying to do it on the >cheap >actually ended up costing more in time and money. >https://schlauhaus.biz/en/product/nanocul-868-kit/ >Now I need to work out the best way to get the info into node red so I >can >then save it in Influxdb and make a web front end for it. > >On Wed, 1 Feb 2023, 18:28 Paul Bayes, ***@***.***> wrote: > >> I agree. See what he says. >> >> On Wed, 1 Feb 2023, 18:11 Peter Price, ***@***.***> wrote: >> >>> Evofw3 configured the card for 868MHz. >>> >>> But t the point is the antenna is not optimised for that frequency. >>> >>> The pictures on the site show the card is printed with 433MHz >>> >>> When I was looking, all the modules that looked like this appeared >to be >>> 433MHz >>> >>> >>> >>> ⁣Get BlueMail for Android ​ >>> >>> On 1 Feb 2023, 08:20, at 08:20, pdbayes ***@***.***> wrote: >>> >This is the sellers response, I have pointed out that you need a >>> >different >>> >design for the external components for the higher frequency band >and >>> >also >>> >that the antenna should be half the length. >>> >New message from: hol-5376 >>> >< >>> > https://www.ebay.co.uk/ulk/usr/hol-5376?mkevt=1&mkpid=0&emsid=e11051.m44.l1181&mkcid=7&ch=osgood&euid=d67b2f6f16d4484780ed2f0a8fed1e3e&bu=45544770190&osub=-1%7E1&crd=20230131165028&segname=11051 >>> > >>> > (18[image: YELLOW_STAR Star]) >>> >< >>> > https://www.ebay.co.uk/fdbk/feedback_profile/hol-5376?mkevt=1&mkpid=0&emsid=e11051.m44.l1183&mkcid=7&ch=osgood&euid=d67b2f6f16d4484780ed2f0a8fed1e3e&bu=45544770190&osub=-1%7E1&crd=20230131165028&segname=11051 >>> > >>> > >>> >Are you using Arduino to program it? >>> > >>> >If so what library? >>> >I've used the Elechouse library, and then you can use the >.setMHZ() >>> >function to set the frequency >>> > >>> >You can enter any number in the range 779 - 928 MHz >>> > >>> >You can have a look here for some examples, and a good guide: >>> >https://github.com/LSatan/SmartRC-CC1101-Driver-Lib >>> > >>> > >>> >On Tue, 31 Jan 2023, 22:48 Paul Bayes, ***@***.***> wrote: >>> > >>> >> That's a good point. It doesn't say which of the frequencies >it's >>> >> configured for. >>> >> I'll mail him. Pain in the bum. >>> >> >>> >> On Tue, 31 Jan 2023, 22:26 Peter Price, ***@***.***> wrote: >>> >> >>> >>> While the cc1101 will operate in all those frequency bands the >>> >circuit >>> >>> between the chip and antenna is different. >>> >>> >>> >>> It's possible that the module you've bought is configured for >433 >>> >MHz. >>> >>> It's very unlikely that you can buy a module that will work at >all >>> >>> frequencies. >>> >>> >>> >>> You should be able to tell by looking closely at the layout of >the >>> >>> components and comparing it to the TI documentation for the >CC1101. >>> >>> >>> >>> ⁣Get BlueMail for Android ​ >>> >>> >>> >>> On 31 Jan 2023, 21:04, at 21:04, pdbayes ***@***.***> wrote: >>> >>> >Hi >>> >>> > >>> >>> >I assume if wired correctly and firmware loaded, I should see >some >>> >data >>> >>> >in >>> >>> >the serial monitor? >>> >>> >I got one of these in the end and cross referenced your >connection >>> >>> >instruction with the E07. >>> >>> > >>> >>> >>> > >>> > https://www.ebay.co.uk/itm/394035907922?mkcid=16&mkevt=1&mkrid=711-127632-2357-0&ssspo=meql5djjqne&sssrc=2349624&ssuid=b_r4gulfrre&var=&widget_ver=artemis&media=COPY >>> >>> > >>> >>> >Currently I only get the firmware version in the monitor. >>> >>> > >>> >>> >On Sun, 29 Jan 2023, 21:16 Paul Bayes, ***@***.***> wrote: >>> >>> > >>> >>> >> Thanks for your help. I'll give it a go later this week. >>> >>> >> >>> >>> >> On Sun, 29 Jan 2023, 19:42 Peter Price, ***@***.***> wrote: >>> >>> >> >>> >>> >>> This is the pinout for the Leonardo I’m referring to and >the >>> >E07 >>> >>> >radio >>> >>> >>> module >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> You need to connect the following >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Leonardo E07 >>> >>> >>> >>> >>> >>> D0/RX 14 >>> >>> >>> >>> >>> >>> D1/TX 15 >>> >>> >>> >>> >>> >>> 3V3 9 >>> >>> >>> >>> >>> >>> GND 12 >>> >>> >>> >>> >>> >>> D10/PB6/SS 19 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> And from the ICSP header (check online for ICSP pinout) >>> >>> >>> >>> >>> >>> MOSI 17 >>> >>> >>> >>> >>> >>> MISO 16 >>> >>> >>> >>> >>> >>> SCK 18 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Some of the E07 pins are probably available elsewhere on >the >>> >dev >>> >>> >card. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Don’t forget you need to make sure the STM8 doesn’t try to >>> >access >>> >>> >the E07 >>> >>> >>> at the same time as the Leonardo >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> From: pdbayes ***@***.*** >>> >>> >>> Sent: 29 January 2023 17:16 >>> >>> >>> To: ghoti57/evofw3 ***@***.***> >>> >>> >>> Cc: Peter Price ***@***.***>; Comment ***@***.***> >>> >>> >>> Subject: Re: [ghoti57/evofw3] STM8 (Issue #35) >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Hi. Got my Leonardo board, serial monitor reports evofw3 >0.7.1. >>> >>> >>> Can you let me know the connections please. >>> >>> >>> Thank you >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Sat, 28 Jan 2023, 19:18 Paul Bayes, ***@***.*** >>> >>> ><mailto:***@***.***> >>> >>> >>> > wrote: >>> >>> >>> >>> >>> >>> > Thanks. I've ordered a Leonardo as I have a prototype >shield >>> >in >>> >>> >this >>> >>> >>> > format, which might help keep things tidy. >>> >>> >>> > >>> >>> >>> > On Sat, 28 Jan 2023, 18:06 Peter Price, ***@***.*** >>> >>> ><mailto:***@***.***> >>> >>> >>> > wrote: >>> >>> >>> > >>> >>> >>> >> You want something with an atmega32u4 processor. This >will >>> >have >>> >>> >a >>> >>> >>> direct >>> >>> >>> >> usb interface to the host (no driver required) and leaves >the >>> >HW >>> >>> >UART >>> >>> >>> free >>> >>> >>> >> to connect to the CC1101. >>> >>> >>> >> >>> >>> >>> >> Avoid atmega328 based devices. >>> >>> >>> >> >>> >>> >>> >> When you have it let me know exactly what you have and >I'll >>> >tell >>> >>> >you >>> >>> >>> the >>> >>> >>> >> connections you need. >>> >>> >>> >> >>> >>> >>> >> ⁣Get BlueMail for Android ​ >>> >>> >>> >> >>> >>> >>> >> On 28 Jan 2023, 16:08, at 16:08, pdbayes ***@***.*** >>> >>> ><mailto:***@***.***> >>> >>> >>> > wrote: >>> >>> >>> >> >Last question I promise. I have a different recover now >with >>> >no >>> >>> >MCU. >>> >>> >>> >> >Which >>> >>> >>> >> >MCU have you found works best. I have an old cloned Nano >but >>> >It >>> >>> >won't >>> >>> >>> >> >load >>> >>> >>> >> >the sketch. I think it has a Chinese rip off usb chip >that's >>> >not >>> >>> >great >>> >>> >>> >> >and >>> >>> >>> >> >that is causing issues. Would the latest Nano be a good >>> >choice. >>> >>> >>> >> > >>> >>> >>> >> >On Fri, 27 Jan 2023, 06:57 Paul Bayes, ***@***.*** >>> >>> ><mailto:***@***.***> >>> >>> >>> > wrote: >>> >>> >>> >> > >>> >>> >>> >> >> I have an Uno so should be ok. Thanks for your help >>> >>> >>> >> >> >>> >>> >>> >> >> On Thu, 26 Jan 2023, 22:06 Peter Price, ***@***.*** >>> >>> ><mailto:***@***.***> >>> >>> >>> > wrote: >>> >>> >>> >> >> >>> >>> >>> >> >>> Just thought. >>> >>> >>> >> >>> >>> >>> >>> >> >>> The power to the e7 will have to come from the >Arduino. >>> >>> >>> >> >>> >>> >>> >>> >> >>> It will also be connected to the STM8 so you need to >be >>> >sure >>> >>> >that >>> >>> >>> >> >it >>> >>> >>> >> >>> doesn't configure it's GOIOs in such a way that it >>> >>> >interferes >>> >>> >>> >> >>> >>> >>> >>> >> >>> ⁣Get BlueMail for Android ​ >>> >>> >>> >> >>> >>> >>> >>> >> >>> On 26 Jan 2023, 22:00, at 22:00, Peter Price >***@***.*** >>> >>> ><mailto:***@***.***> >>> >>> >>> > wrote: >>> >>> >>> >> >>> >If you have an Arduino with an atmega32u4 or a >16MHz >>> >>> >atmega328p >>> >>> >>> and >>> >>> >>> >> >you >>> >>> >>> >> >>> >connect it correctly it will work with no code >changes. >>> >>> >>> >> >>> > >>> >>> >>> >> >>> >If you only have an 8MHz atmega328p it won't. >>> >>> >>> >> >>> > >>> >>> >>> >> >>> >⁣Get BlueMail for Android ​ >>> >>> >>> >> >>> > >>> >>> >>> >> >>> >On 26 Jan 2023, 20:00, at 20:00, pdbayes >***@***.*** >>> >>> ><mailto:***@***.***> >>> >>> >>> > >>> >>> >>> >> >>> >wrote: >>> >>> >>> >> >>> >>Hmmm. I wonder if I could hard wire the GDO pins >from >>> >the >>> >>> >e07 >>> >>> >>> >> >module >>> >>> >>> >> >>> >to >>> >>> >>> >> >>> >>an >>> >>> >>> >> >>> >>Arduino I have spare? Will depend on what the STM8 >is >>> >doing >>> >>> >on >>> >>> >>> >> >those >>> >>> >>> >> >>> >>pins >>> >>> >>> >> >>> >>or any intermediate components. Or maybe using >software >>> >on >>> >>> >the >>> >>> >>> >> >STM8 >>> >>> >>> >> >>> >>the >>> >>> >>> >> >>> >>recieved data could be sent as is to an io pin. >>> >>> >>> >> >>> >> >>> >>> >>> >> >>> >>On Thu, 26 Jan 2023, 18:22 Peter Price, >***@***.*** >>> >>> ><mailto:***@***.***> >>> >>> >>> > wrote: >>> >>> >>> >> >>> >> >>> >>> >>> >> >>> >>> I think you've misunderstood about the UART in >the >>> >>> >context of >>> >>> >>> >> >>> >>evofw3. >>> >>> >>> >> >>> >>> >>> >>> >>> >> >>> >>> The bitstream that comes out of the cc1101 in an >>> >evohome >>> >>> >>> >> >environment >>> >>> >>> >> >>> >>has >>> >>> >>> >> >>> >>> effectively been generated by UARTs in the Evo >>> >devices >>> >>> >>> >> >(controller, >>> >>> >>> >> >>> >>rad >>> >>> >>> >> >>> >>> stats, thermostats etc) >>> >>> >>> >> >>> >>> >>> >>> >>> >> >>> >>> This means you need a UART interface in the STM8 >>> >facing >>> >>> >the >>> >>> >>> >> >CC1101. >>> >>> >>> >> >>> >>> >>> >>> >>> >> >>> >>> On your Dev board the HW UART in the STM8 is >almost >>> >>> >certainly >>> >>> >>> >> >>> >>connected to >>> >>> >>> >> >>> >>> the USB connector on the board. >>> >>> >>> >> >>> >>> >>> >>> >>> >> >>> >>> This means the connection to GDO0 and GD02 of >the >>> >CC1101 >>> >>> >will >>> >>> >>> >> >be >>> >>> >>> >> >>> >>using two >>> >>> >>> >> >>> >>> ordinary GPIO signals. That means you have to >>> >implement a >>> >>> >SW >>> >>> >>> >> >UART >>> >>> >>> >> >>> >in >>> >>> >>> >> >>> >>the >>> >>> >>> >> >>> >>> STM8 to decode the bitstream. You have to be able >to >>> >>> >>> >> >synchronise >>> >>> >>> >> >>> >>with the >>> >>> >>> >> >>> >>> stop/start bits in the bitstream so that you can >>> >identify >>> >>> >and >>> >>> >>> >> >>> >extract >>> >>> >>> >> >>> >>the >>> >>> >>> >> >>> >>> real data. >>> >>> >>> >> >>> >>> >>> >>> >>> >> >>> >>> You are not dealing with a synchronous system. >It's >>> >>> >>> >> >asynchronous >>> >>> >>> >> >>> >>because >>> >>> >>> >> >>> >>> all the devices have their own clock and they're >all >>> >>> >slightly >>> >>> >>> >> >>> >>different. >>> >>> >>> >> >>> >>> >>> >>> >>> >> >>> >>> You're dealing with a bit stream at 38400 baud >with >>> >>> >significant >>> >>> >>> >> >>> >>jitter >>> >>> >>> >> >>> >>> generated by some of the devices you are >listening >>> >to. >>> >>> >>> >> >>> >>> >>> >>> >>> >> >>> >>> I very much doubt that the example software will >get >>> >>> >anywhere >>> >>> >>> >> >near >>> >>> >>> >> >>> >>> extracting the data you need. >>> >>> >>> >> >>> >>> >>> >>> >>> >> >>> >>> >>> >>> >>> >> >>> >>> >>> >>> >>> >> >>> >>> ⁣Get BlueMail for Android ​ >>> >>> >>> >> >>> >>> >>> >>> >>> >> >>> >>> On 26 Jan 2023, 15:04, at 15:04, pdbayes >***@***.*** >>> >>> ><mailto:***@***.***> >>> >>> >>> > wrote: >>> >>> >>> >> >>> >>> >Thanks for the advice. >>> >>> >>> >> >>> >>> >The dev board is this: >>> >>> >>> >> >>> >>> >>> >>https://www.ebyte.com/en/product-view-news.html?id=1691 >>> >>> >>> >> >>> >>> >All the UART side of things should be handled >and I >>> >was >>> >>> >hoping >>> >>> >>> >> >I >>> >>> >>> >> >>> >>would >>> >>> >>> >> >>> >>> >just >>> >>> >>> >> >>> >>> >have a stream of bits to deal with on the >pi/pc. >>> >They >>> >>> >say it >>> >>> >>> >> >comes >>> >>> >>> >> >>> >>> >with >>> >>> >>> >> >>> >>> >example software to do this but it is within a >>> >>> >commercial IDE >>> >>> >>> >> >you >>> >>> >>> >> >>> >>have >>> >>> >>> >> >>> >>> >to >>> >>> >>> >> >>> >>> >pay for. It has a free trial so hopefully that >will >>> >give >>> >>> >me >>> >>> >>> >> >enough >>> >>> >>> >> >>> >>time >>> >>> >>> >> >>> >>> >to >>> >>> >>> >> >>> >>> >get it working. >>> >>> >>> >> >>> >>> > >>> >>> >>> >> >>> >>> >On Thu, 26 Jan 2023 at 14:32, Peter Price >>> >***@***.*** >>> >>> ><mailto:***@***.***> >>> >>> >>> > wrote: >>> >>> >>> >> >>> >>> > >>> >>> >>> >> >>> >>> >> Good luck with that :-) >>> >>> >>> >> >>> >>> >> >>> >>> >>> >> >>> >>> >> The code has a lot of atmega specific code >for >>> >the >>> >>> >hardware >>> >>> >>> >> >>> >>> >interface. >>> >>> >>> >> >>> >>> >> Because of the overhead the code doesn't use >the >>> >>> >Arduino IO >>> >>> >>> >> >>> >>functions >>> >>> >>> >> >>> >>> >but >>> >>> >>> >> >>> >>> >> drives the GPIO pins directly via the >registers. >>> >>> >>> >> >>> >>> >> >>> >>> >>> >> >>> >>> >> TX uses the SPI interface to fill the cc1101 >TX >>> >fifo, >>> >>> >but, >>> >>> >>> >> >>> >because >>> >>> >>> >> >>> >>of >>> >>> >>> >> >>> >>> >the >>> >>> >>> >> >>> >>> >> jitter on the incoming signals from the other >>> >devices, >>> >>> >you >>> >>> >>> >> >can't >>> >>> >>> >> >>> >>use >>> >>> >>> >> >>> >>> >the >>> >>> >>> >> >>> >>> >> cc1101 rx fifo to capture the data because it >>> >assumes >>> >>> >>> >> >everything >>> >>> >>> >> >>> >>is >>> >>> >>> >> >>> >>> >> synchronous. >>> >>> >>> >> >>> >>> >> >>> >>> >>> >> >>> >>> >> If you try a port then I suggest you get the >SPI >>> >>> >interface >>> >>> >>> to >>> >>> >>> >> >the >>> >>> >>> >> >>> >>> >CC1101 >>> >>> >>> >> >>> >>> >> working first and then the HW UART interface >>> >between >>> >>> >the STM >>> >>> >>> >> >and >>> >>> >>> >> >>> >>the >>> >>> >>> >> >>> >>> >> CC1101. This is just an ISR triggered by the >UART >>> >that >>> >>> >reads >>> >>> >>> >> >the >>> >>> >>> >> >>> >>UART >>> >>> >>> >> >>> >>> >RX >>> >>> >>> >> >>> >>> >> data into a buffer. >>> >>> >>> >> >>> >>> >> >>> >>> >>> >> >>> >>> >> If the STM hasn't got a HW UART available >then >>> >you'll >>> >>> >need >>> >>> >>> to >>> >>> >>> >> >be >>> >>> >>> >> >>> >>good >>> >>> >>> >> >>> >>> >at >>> >>> >>> >> >>> >>> >> coding. I suspect the STM8 HW UART has been >>> >connected >>> >>> >to the >>> >>> >>> >> >host >>> >>> >>> >> >>> >>> >USB >>> >>> >>> >> >>> >>> >> interface so this is going to be the case. >>> >>> >>> >> >>> >>> >> >>> >>> >>> >> >>> >>> >> The atmega328p SW UART code uses a HW >interrupt >>> >to >>> >>> >capture >>> >>> >>> >> >the >>> >>> >>> >> >>> >>timing >>> >>> >>> >> >>> >>> >of >>> >>> >>> >> >>> >>> >> the signal edges and then a SW trap to >process >>> >the >>> >>> >captured >>> >>> >>> >> >data >>> >>> >>> >> >>> >>> >edges to >>> >>> >>> >> >>> >>> >> generate an RX byte. This is very processor >heavy >>> >and >>> >>> >every >>> >>> >>> >> >cycle >>> >>> >>> >> >>> >>is >>> >>> >>> >> >>> >>> >> critical to keep up with the data when it >arrives. >>> >The >>> >>> >SW >>> >>> >>> >> >UART >>> >>> >>> >> >>> >>won't >>> >>> >>> >> >>> >>> >work >>> >>> >>> >> >>> >>> >> on an atmega clocked at less than 16MHz >because >>> >there >>> >>> >aren't >>> >>> >>> >> >>> >>enough >>> >>> >>> >> >>> >>> >> instruction cycles available. >>> >>> >>> >> >>> >>> >> >>> >>> >>> >> >>> >>> >> The SW UART code is not as good at RXing >radio >>> >>> >messages as >>> >>> >>> >> >the HW >>> >>> >>> >> >>> >>> >UART >>> >>> >>> >> >>> >>> >> code. >>> >>> >>> >> >>> >>> >> >>> >>> >>> >> >>> >>> >> Using a simple USB logic analyser ( e.g. >>> >>> >>> >> >>> >>> >> >>> >>> >>> >> >>> >>> > >>> >>> >>> >> >>> >>> >>> >>> >>> >> >>> >> >>> >>> >>> >> >>> >>> >>> >>> >> > >>> >>> >>> >> >>> >>> >>> >>> >>> > >>> >>> >>> > >>> > https://www.amazon.co.uk/Hobby-Components-24MHz-Analyser-1-1-16/dp/B00DAYAREW >>> >>> >>> >> >>> >>> ) >>> >>> >>> >> >>> >>> >> there are some debug lines still in the code >that >>> >you >>> >>> >can >>> >>> >>> use >>> >>> >>> >> >to >>> >>> >>> >> >>> >>> >drive >>> >>> >>> >> >>> >>> >> spare GPIO pins that will show you how much >>> >processor >>> >>> >time >>> >>> >>> >> >you're >>> >>> >>> >> >>> >>> >using in >>> >>> >>> >> >>> >>> >> the HW and SW ISR functions. >>> >>> >>> >> >>> >>> >> >>> >>> >>> >> >>> >>> >> The frame, message and host interface code >should >>> >>> >work >>> >>> >>> >> >without >>> >>> >>> >> >>> >>> >significant >>> >>> >>> >> >>> >>> >> changes. >>> >>> >>> >> >>> >>> >> >>> >>> >>> >> >>> >>> >> That's all the help I can offer since I have >zero >>> >STM >>> >>> >>> >> >knowledge. >>> >>> >>> >> >>> >>> >> >>> >>> >>> >> >>> >>> >> If you don't understand what I've said above >give >>> >up >>> >>> >now. >>> >>> >>> >> >>> >>> >> >>> >>> >>> >> >>> >>> >> — >>> >>> >>> >> >>> >>> >> Reply to this email directly, view it on >GitHub >>> >>> >>> >> >>> >>> >> >>> >>> >>> >> >>> >>> >>> >>> >>> >> >>> >>> >>> >>> >> >>>>< >>> >>> >>> >>> >>#35 (comment) >>> >>> >< >>> >>> >>> >>> >>#35 (comment) >>> >>> >> >>> >>> >>> >> >, >>> >>> >>> >> >>> >>> >or >>> >>> >>> >> >>> >>> >> unsubscribe >>> >>> >>> >> >>> >>> >> >>> >>> >>> >> >>> >>> >< >>> >>> >>> >> >>> >>> >>> >>> >>> >> >>> >> >>> >>> >>> >> >>> >>> >>> >>> >> > >>> >>> >>> >> >>> >>> >>> >>> >>> > >>> >>> >>> > >>> > https://github.com/notifications/unsubscribe-auth/AN4GHPSSWORQMO6CGL6XQV3WUKDJNANCNFSM6AAAAAAUHJSYXI >>> >>> >>> >> >>> >>> > >>> >>> >>> >> >>> >>> >> . >>> >>> >>> >> >>> >>> >> You are receiving this because you authored >the >>> >>> >>> >> >thread.Message >>> >>> >>> >> >>> >>ID: >>> >>> >>> >> >>> >>> >> ***@***.*** <mailto:***@***.***> > >>> >>> >>> >> >>> >>> >> >>> >>> >>> >> >>> >>> > >>> >>> >>> >> >>> >>> > >>> >>> >>> >> >>> >>> >-- >>> >>> >>> >> >>> >>> >Reply to this email directly or view it on >GitHub: >>> >>> >>> >> >>> >>> >>> >>> >>> >> >>> >>> >>> >>>>>#35 (comment) >>> >>> >>> >> >>> >>> >You are receiving this because you commented. >>> >>> >>> >> >>> >>> > >>> >>> >>> >> >>> >>> >Message ID: ***@***.*** <mailto:***@***.***> > >>> >>> >>> >> >>> >>> >>> >>> >>> >> >>> >>> — >>> >>> >>> >> >>> >>> Reply to this email directly, view it on GitHub >>> >>> >>> >> >>> >>> >>> >>> >>> >> >>> >>> >>> >>> >> >>>< >>> >>> >>> >>> >>> >>> >>>#35 (comment)>, >>> >>> >>> >> >>> >>or >>> >>> >>> >> >>> >>> unsubscribe >>> >>> >>> >> >>> >>> >>> >>> >>> >> >>> >>< >>> >>> >>> >> >>> >>> >>> >>> >> > >>> >>> >>> >> >>> >>> >>> >>> >>> > >>> >>> >>> > >>> > https://github.com/notifications/unsubscribe-auth/AN4GHPWOTGSC3DO2F7TN4M3WUK6FHANCNFSM6AAAAAAUHJSYXI >>> >>> >>> >> >>> > >>> >>> >>> >> >>> >>> . >>> >>> >>> >> >>> >>> You are receiving this because you authored the >>> >>> >thread.Message >>> >>> >>> >> >ID: >>> >>> >>> >> >>> >>> ***@***.*** <mailto:***@***.***> > >>> >>> >>> >> >>> >>> >>> >>> >>> >> >>> >> >>> >>> >>> >> >>> >> >>> >>> >>> >> >>> >>-- >>> >>> >>> >> >>> >>Reply to this email directly or view it on GitHub: >>> >>> >>> >> >>> >>> >>> >>> >> >>> >>> >>> >>>>>>#35 (comment) >>> >>> >>> >> >>> >>You are receiving this because you commented. >>> >>> >>> >> >>> >> >>> >>> >>> >> >>> >>Message ID: ***@***.*** <mailto:***@***.***> > >>> >>> >>> >> >>> >>> >>> >>> >> >>> — >>> >>> >>> >> >>> Reply to this email directly, view it on GitHub >>> >>> >>> >> >>> >>> >>> >>> >> >>> >>> >>> >>>><#35 (comment) >>> >>> >>> >, >>> >>> >>> >> >>> or unsubscribe >>> >>> >>> >> >>> >>> >>> >>> >> >< >>> >>> >>> >> >>> >>> >>> >>> >>> > >>> >>> >>> > >>> > https://github.com/notifications/unsubscribe-auth/AN4GHPWDEQVBRFCQWOYLZOLWULYNPANCNFSM6AAAAAAUHJSYXI >>> >>> >>> >> > >>> >>> >>> >> >>> . >>> >>> >>> >> >>> You are receiving this because you authored the >>> >>> >thread.Message ID: >>> >>> >>> >> >>> ***@***.*** <mailto:***@***.***> > >>> >>> >>> >> >>> >>> >>> >>> >> >> >>> >>> >>> >> > >>> >>> >>> >> > >>> >>> >>> >> >-- >>> >>> >>> >> >Reply to this email directly or view it on GitHub: >>> >>> >>> >> >>> >>> >>> >>>>#35 (comment) >>> >>> >>> >> >You are receiving this because you commented. >>> >>> >>> >> > >>> >>> >>> >> >Message ID: ***@***.*** <mailto:***@***.***> > >>> >>> >>> >> >>> >>> >>> >> — >>> >>> >>> >> Reply to this email directly, view it on GitHub >>> >>> >>> >> >>> >>> >>> >>><#35 (comment)>, >>> >>> >>> >> or unsubscribe >>> >>> >>> >> < >>> >>> >>> >>> >>> > >>> >>> >>> > >>> > https://github.com/notifications/unsubscribe-auth/AN4GHPWNBGQWDHVC25NK6GLWUVN2ZANCNFSM6AAAAAAUHJSYXI >>> >>> >>> > >>> >>> >>> >> . >>> >>> >>> >> You are receiving this because you authored the >>> >thread.Message >>> >>> >ID: >>> >>> >>> >> ***@***.*** <mailto:***@***.***> > >>> >>> >>> >> >>> >>> >>> > >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> — >>> >>> >>> Reply to this email directly, view it on GitHub < >>> >>> >>> >>> >>#35 (comment)> >>> >>> >, >>> >>> >>> or unsubscribe < >>> >>> >>> >>> >>> > >>> >>> >>> > >>> > https://github.com/notifications/unsubscribe-auth/AIRU2WZ6QZ2JTH4S7JDX2OLWU2QWFANCNFSM6AAAAAAUHJSYXI >>> >>> > >>> >>> >>> . >>> >>> >>> You are receiving this because you commented. < >>> >>> >>> >>> >>> > >>> >>> >>> > >>> > https://github.com/notifications/beacon/AIRU2W6ZSCHUD2NWHFVREOTWU2QWFA5CNFSM6AAAAAAUHJSYXKWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTST5ANTO.gif >>> >>> > >>> >>> >>> Message ID: < ***@***.***> ***@***.***> >>> >>> >>> >>> >>> >>> — >>> >>> >>> Reply to this email directly, view it on GitHub >>> >>> >>> >>> >>> >>> >>><#35 (comment)>, >>> >>> >>> or unsubscribe >>> >>> >>> >>> >>> >< >>> >>> >>> > >>> > https://github.com/notifications/unsubscribe-auth/AN4GHPWVQWX2H6DMZ7ZWXZTWU3B2XANCNFSM6AAAAAAUHJSYXI >>> >>> > >>> >>> >>> . >>> >>> >>> You are receiving this because you authored the >thread.Message >>> >ID: >>> >>> >>> ***@***.***> >>> >>> >>> >>> >>> >> >>> >>> > >>> >>> > >>> >>> >-- >>> >>> >Reply to this email directly or view it on GitHub: >>> >>> >>> >>>#35 (comment) >>> >>> >You are receiving this because you commented. >>> >>> > >>> >>> >Message ID: ***@***.***> >>> >>> >>> >>> — >>> >>> Reply to this email directly, view it on GitHub >>> >>> >>> >><#35 (comment)>, >>> >>> or unsubscribe >>> >>> >>> >< >>> > https://github.com/notifications/unsubscribe-auth/AN4GHPQ66E3C37NVCBNLY4LWVGGSVANCNFSM6AAAAAAUHJSYXI >>> > >>> >>> . >>> >>> You are receiving this because you authored the thread.Message >ID: >>> >>> ***@***.***> >>> >>> >>> >> >>> > >>> > >>> >-- >>> >Reply to this email directly or view it on GitHub: >>> >>#35 (comment) >>> >You are receiving this because you commented. >>> > >>> >Message ID: ***@***.***> >>> >>> — >>> Reply to this email directly, view it on GitHub >>> ><#35 (comment)>, >>> or unsubscribe >>> >< https://github.com/notifications/unsubscribe-auth/AN4GHPTQPA4ZFLA47AKROBTWVKRLRANCNFSM6AAAAAAUHJSYXI > >>> . >>> You are receiving this because you authored the thread.Message ID: >>> ***@***.***> >>> >> > > >-- >Reply to this email directly or view it on GitHub: >#35 (comment) >You are receiving this because you commented. > >Message ID: ***@***.***> — Reply to this email directly, view it on GitHub <#35 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AN4GHPXDWJKR23KS45BMOT3WV6C2FANCNFSM6AAAAAAUHJSYXI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

On Sun, 5 Feb 2023, 11:41 Paul Bayes, ***@***.***> wrote: Hi This one had the option of being preloaded with evofw3 which is what I went for. Hopefully that helps. On Sun, 5 Feb 2023, 11:08 Peter Price, ***@***.***> wrote: > That's probably not the best choice of a processor board. > > They are listing options for usb/serial chips which means that the HW > UART in the processor is being used for the host interfaces and not the > radio interface. > > That means any attempt to extract the data from the radio is limited to > SW UART code. It works but not as effectively as a HW UART. > > The processor is almost certainly an atmega328p. If it doesn't run at > 16MHz it doesn't have enough processor cycles to run the SW UART. > > If you want to run evofw3 you won't be able to use the Arduino gui to > update the firmware. The CUL sticks use a different bootloader. > > The CUL firmware claims to be able to receive evohome messages but the > method it uses cannot deal with some of the variations it might encounter. > > ⁣Get BlueMail for Android ​ > > On 5 Feb 2023, 09:44, at 09:44, pdbayes ***@***.***> wrote: > >Well, this turned into a bit of a saga on eBay. If you are interested I > >can > >fill you in. > >In the end I decided to get one of these as trying to do it on the > >cheap > >actually ended up costing more in time and money. > >https://schlauhaus.biz/en/product/nanocul-868-kit/ > >Now I need to work out the best way to get the info into node red so I > >can > >then save it in Influxdb and make a web front end for it. > > > >On Wed, 1 Feb 2023, 18:28 Paul Bayes, ***@***.***> wrote: > > > >> I agree. See what he says. > >> > >> On Wed, 1 Feb 2023, 18:11 Peter Price, ***@***.***> wrote: > >> > >>> Evofw3 configured the card for 868MHz. > >>> > >>> But t the point is the antenna is not optimised for that frequency. > >>> > >>> The pictures on the site show the card is printed with 433MHz > >>> > >>> When I was looking, all the modules that looked like this appeared > >to be > >>> 433MHz > >>> > >>> > >>> > >>> ⁣Get BlueMail for Android ​ > >>> > >>> On 1 Feb 2023, 08:20, at 08:20, pdbayes ***@***.***> wrote: > >>> >This is the sellers response, I have pointed out that you need a > >>> >different > >>> >design for the external components for the higher frequency band > >and > >>> >also > >>> >that the antenna should be half the length. > >>> >New message from: hol-5376 > >>> >< > >>> > > > https://www.ebay.co.uk/ulk/usr/hol-5376?mkevt=1&mkpid=0&emsid=e11051.m44.l1181&mkcid=7&ch=osgood&euid=d67b2f6f16d4484780ed2f0a8fed1e3e&bu=45544770190&osub=-1%7E1&crd=20230131165028&segname=11051 > >>> > > >>> > (18[image: YELLOW_STAR Star]) > >>> >< > >>> > > > https://www.ebay.co.uk/fdbk/feedback_profile/hol-5376?mkevt=1&mkpid=0&emsid=e11051.m44.l1183&mkcid=7&ch=osgood&euid=d67b2f6f16d4484780ed2f0a8fed1e3e&bu=45544770190&osub=-1%7E1&crd=20230131165028&segname=11051 > >>> > > >>> > > >>> >Are you using Arduino to program it? > >>> > > >>> >If so what library? > >>> >I've used the Elechouse library, and then you can use the > >.setMHZ() > >>> >function to set the frequency > >>> > > >>> >You can enter any number in the range 779 - 928 MHz > >>> > > >>> >You can have a look here for some examples, and a good guide: > >>> >https://github.com/LSatan/SmartRC-CC1101-Driver-Lib > >>> > > >>> > > >>> >On Tue, 31 Jan 2023, 22:48 Paul Bayes, ***@***.***> wrote: > >>> > > >>> >> That's a good point. It doesn't say which of the frequencies > >it's > >>> >> configured for. > >>> >> I'll mail him. Pain in the bum. > >>> >> > >>> >> On Tue, 31 Jan 2023, 22:26 Peter Price, ***@***.***> wrote: > >>> >> > >>> >>> While the cc1101 will operate in all those frequency bands the > >>> >circuit > >>> >>> between the chip and antenna is different. > >>> >>> > >>> >>> It's possible that the module you've bought is configured for > >433 > >>> >MHz. > >>> >>> It's very unlikely that you can buy a module that will work at > >all > >>> >>> frequencies. > >>> >>> > >>> >>> You should be able to tell by looking closely at the layout of > >the > >>> >>> components and comparing it to the TI documentation for the > >CC1101. > >>> >>> > >>> >>> ⁣Get BlueMail for Android ​ > >>> >>> > >>> >>> On 31 Jan 2023, 21:04, at 21:04, pdbayes ***@***.***> wrote: > >>> >>> >Hi > >>> >>> > > >>> >>> >I assume if wired correctly and firmware loaded, I should see > >some > >>> >data > >>> >>> >in > >>> >>> >the serial monitor? > >>> >>> >I got one of these in the end and cross referenced your > >connection > >>> >>> >instruction with the E07. > >>> >>> > > >>> >>> > >>> > > >>> > > > https://www.ebay.co.uk/itm/394035907922?mkcid=16&mkevt=1&mkrid=711-127632-2357-0&ssspo=meql5djjqne&sssrc=2349624&ssuid=b_r4gulfrre&var=&widget_ver=artemis&media=COPY > >>> >>> > > >>> >>> >Currently I only get the firmware version in the monitor. > >>> >>> > > >>> >>> >On Sun, 29 Jan 2023, 21:16 Paul Bayes, ***@***.***> wrote: > >>> >>> > > >>> >>> >> Thanks for your help. I'll give it a go later this week. > >>> >>> >> > >>> >>> >> On Sun, 29 Jan 2023, 19:42 Peter Price, ***@***.***> wrote: > >>> >>> >> > >>> >>> >>> This is the pinout for the Leonardo I’m referring to and > >the > >>> >E07 > >>> >>> >radio > >>> >>> >>> module > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> You need to connect the following > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> Leonardo E07 > >>> >>> >>> > >>> >>> >>> D0/RX 14 > >>> >>> >>> > >>> >>> >>> D1/TX 15 > >>> >>> >>> > >>> >>> >>> 3V3 9 > >>> >>> >>> > >>> >>> >>> GND 12 > >>> >>> >>> > >>> >>> >>> D10/PB6/SS 19 > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> And from the ICSP header (check online for ICSP pinout) > >>> >>> >>> > >>> >>> >>> MOSI 17 > >>> >>> >>> > >>> >>> >>> MISO 16 > >>> >>> >>> > >>> >>> >>> SCK 18 > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> Some of the E07 pins are probably available elsewhere on > >the > >>> >dev > >>> >>> >card. > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> Don’t forget you need to make sure the STM8 doesn’t try to > >>> >access > >>> >>> >the E07 > >>> >>> >>> at the same time as the Leonardo > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> From: pdbayes ***@***.*** > >>> >>> >>> Sent: 29 January 2023 17:16 > >>> >>> >>> To: ghoti57/evofw3 ***@***.***> > >>> >>> >>> Cc: Peter Price ***@***.***>; Comment ***@***.***> > >>> >>> >>> Subject: Re: [ghoti57/evofw3] STM8 (Issue #35) > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> Hi. Got my Leonardo board, serial monitor reports evofw3 > >0.7.1. > >>> >>> >>> Can you let me know the connections please. > >>> >>> >>> Thank you > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> On Sat, 28 Jan 2023, 19:18 Paul Bayes, ***@***.*** > >>> >>> ><mailto:***@***.***> > >>> >>> >>> > wrote: > >>> >>> >>> > >>> >>> >>> > Thanks. I've ordered a Leonardo as I have a prototype > >shield > >>> >in > >>> >>> >this > >>> >>> >>> > format, which might help keep things tidy. > >>> >>> >>> > > >>> >>> >>> > On Sat, 28 Jan 2023, 18:06 Peter Price, ***@***.*** > >>> >>> ><mailto:***@***.***> > >>> >>> >>> > wrote: > >>> >>> >>> > > >>> >>> >>> >> You want something with an atmega32u4 processor. This > >will > >>> >have > >>> >>> >a > >>> >>> >>> direct > >>> >>> >>> >> usb interface to the host (no driver required) and leaves > >the > >>> >HW > >>> >>> >UART > >>> >>> >>> free > >>> >>> >>> >> to connect to the CC1101. > >>> >>> >>> >> > >>> >>> >>> >> Avoid atmega328 based devices. > >>> >>> >>> >> > >>> >>> >>> >> When you have it let me know exactly what you have and > >I'll > >>> >tell > >>> >>> >you > >>> >>> >>> the > >>> >>> >>> >> connections you need. > >>> >>> >>> >> > >>> >>> >>> >> ⁣Get BlueMail for Android ​ > >>> >>> >>> >> > >>> >>> >>> >> On 28 Jan 2023, 16:08, at 16:08, pdbayes ***@***.*** > >>> >>> ><mailto:***@***.***> > >>> >>> >>> > wrote: > >>> >>> >>> >> >Last question I promise. I have a different recover now > >with > >>> >no > >>> >>> >MCU. > >>> >>> >>> >> >Which > >>> >>> >>> >> >MCU have you found works best. I have an old cloned Nano > >but > >>> >It > >>> >>> >won't > >>> >>> >>> >> >load > >>> >>> >>> >> >the sketch. I think it has a Chinese rip off usb chip > >that's > >>> >not > >>> >>> >great > >>> >>> >>> >> >and > >>> >>> >>> >> >that is causing issues. Would the latest Nano be a good > >>> >choice. > >>> >>> >>> >> > > >>> >>> >>> >> >On Fri, 27 Jan 2023, 06:57 Paul Bayes, ***@***.*** > >>> >>> ><mailto:***@***.***> > >>> >>> >>> > wrote: > >>> >>> >>> >> > > >>> >>> >>> >> >> I have an Uno so should be ok. Thanks for your help > >>> >>> >>> >> >> > >>> >>> >>> >> >> On Thu, 26 Jan 2023, 22:06 Peter Price, ***@***.*** > >>> >>> ><mailto:***@***.***> > >>> >>> >>> > wrote: > >>> >>> >>> >> >> > >>> >>> >>> >> >>> Just thought. > >>> >>> >>> >> >>> > >>> >>> >>> >> >>> The power to the e7 will have to come from the > >Arduino. > >>> >>> >>> >> >>> > >>> >>> >>> >> >>> It will also be connected to the STM8 so you need to > >be > >>> >sure > >>> >>> >that > >>> >>> >>> >> >it > >>> >>> >>> >> >>> doesn't configure it's GOIOs in such a way that it > >>> >>> >interferes > >>> >>> >>> >> >>> > >>> >>> >>> >> >>> ⁣Get BlueMail for Android ​ > >>> >>> >>> >> >>> > >>> >>> >>> >> >>> On 26 Jan 2023, 22:00, at 22:00, Peter Price > >***@***.*** > >>> >>> ><mailto:***@***.***> > >>> >>> >>> > wrote: > >>> >>> >>> >> >>> >If you have an Arduino with an atmega32u4 or a > >16MHz > >>> >>> >atmega328p > >>> >>> >>> and > >>> >>> >>> >> >you > >>> >>> >>> >> >>> >connect it correctly it will work with no code > >changes. > >>> >>> >>> >> >>> > > >>> >>> >>> >> >>> >If you only have an 8MHz atmega328p it won't. > >>> >>> >>> >> >>> > > >>> >>> >>> >> >>> >⁣Get BlueMail for Android ​ > >>> >>> >>> >> >>> > > >>> >>> >>> >> >>> >On 26 Jan 2023, 20:00, at 20:00, pdbayes > >***@***.*** > >>> >>> ><mailto:***@***.***> > >>> >>> >>> > > >>> >>> >>> >> >>> >wrote: > >>> >>> >>> >> >>> >>Hmmm. I wonder if I could hard wire the GDO pins > >from > >>> >the > >>> >>> >e07 > >>> >>> >>> >> >module > >>> >>> >>> >> >>> >to > >>> >>> >>> >> >>> >>an > >>> >>> >>> >> >>> >>Arduino I have spare? Will depend on what the STM8 > >is > >>> >doing > >>> >>> >on > >>> >>> >>> >> >those > >>> >>> >>> >> >>> >>pins > >>> >>> >>> >> >>> >>or any intermediate components. Or maybe using > >software > >>> >on > >>> >>> >the > >>> >>> >>> >> >STM8 > >>> >>> >>> >> >>> >>the > >>> >>> >>> >> >>> >>recieved data could be sent as is to an io pin. > >>> >>> >>> >> >>> >> > >>> >>> >>> >> >>> >>On Thu, 26 Jan 2023, 18:22 Peter Price, > >***@***.*** > >>> >>> ><mailto:***@***.***> > >>> >>> >>> > wrote: > >>> >>> >>> >> >>> >> > >>> >>> >>> >> >>> >>> I think you've misunderstood about the UART in > >the > >>> >>> >context of > >>> >>> >>> >> >>> >>evofw3. > >>> >>> >>> >> >>> >>> > >>> >>> >>> >> >>> >>> The bitstream that comes out of the cc1101 in an > >>> >evohome > >>> >>> >>> >> >environment > >>> >>> >>> >> >>> >>has > >>> >>> >>> >> >>> >>> effectively been generated by UARTs in the Evo > >>> >devices > >>> >>> >>> >> >(controller, > >>> >>> >>> >> >>> >>rad > >>> >>> >>> >> >>> >>> stats, thermostats etc) > >>> >>> >>> >> >>> >>> > >>> >>> >>> >> >>> >>> This means you need a UART interface in the STM8 > >>> >facing > >>> >>> >the > >>> >>> >>> >> >CC1101. > >>> >>> >>> >> >>> >>> > >>> >>> >>> >> >>> >>> On your Dev board the HW UART in the STM8 is > >almost > >>> >>> >certainly > >>> >>> >>> >> >>> >>connected to > >>> >>> >>> >> >>> >>> the USB connector on the board. > >>> >>> >>> >> >>> >>> > >>> >>> >>> >> >>> >>> This means the connection to GDO0 and GD02 of > >the > >>> >CC1101 > >>> >>> >will > >>> >>> >>> >> >be > >>> >>> >>> >> >>> >>using two > >>> >>> >>> >> >>> >>> ordinary GPIO signals. That means you have to > >>> >implement a > >>> >>> >SW > >>> >>> >>> >> >UART > >>> >>> >>> >> >>> >in > >>> >>> >>> >> >>> >>the > >>> >>> >>> >> >>> >>> STM8 to decode the bitstream. You have to be able > >to > >>> >>> >>> >> >synchronise > >>> >>> >>> >> >>> >>with the > >>> >>> >>> >> >>> >>> stop/start bits in the bitstream so that you can > >>> >identify > >>> >>> >and > >>> >>> >>> >> >>> >extract > >>> >>> >>> >> >>> >>the > >>> >>> >>> >> >>> >>> real data. > >>> >>> >>> >> >>> >>> > >>> >>> >>> >> >>> >>> You are not dealing with a synchronous system. > >It's > >>> >>> >>> >> >asynchronous > >>> >>> >>> >> >>> >>because > >>> >>> >>> >> >>> >>> all the devices have their own clock and they're > >all > >>> >>> >slightly > >>> >>> >>> >> >>> >>different. > >>> >>> >>> >> >>> >>> > >>> >>> >>> >> >>> >>> You're dealing with a bit stream at 38400 baud > >with > >>> >>> >significant > >>> >>> >>> >> >>> >>jitter > >>> >>> >>> >> >>> >>> generated by some of the devices you are > >listening > >>> >to. > >>> >>> >>> >> >>> >>> > >>> >>> >>> >> >>> >>> I very much doubt that the example software will > >get > >>> >>> >anywhere > >>> >>> >>> >> >near > >>> >>> >>> >> >>> >>> extracting the data you need. > >>> >>> >>> >> >>> >>> > >>> >>> >>> >> >>> >>> > >>> >>> >>> >> >>> >>> > >>> >>> >>> >> >>> >>> ⁣Get BlueMail for Android ​ > >>> >>> >>> >> >>> >>> > >>> >>> >>> >> >>> >>> On 26 Jan 2023, 15:04, at 15:04, pdbayes > >***@***.*** > >>> >>> ><mailto:***@***.***> > >>> >>> >>> > wrote: > >>> >>> >>> >> >>> >>> >Thanks for the advice. > >>> >>> >>> >> >>> >>> >The dev board is this: > >>> >>> >>> >> >>> >>> > >>> >>https://www.ebyte.com/en/product-view-news.html?id=1691 > >>> >>> >>> >> >>> >>> >All the UART side of things should be handled > >and I > >>> >was > >>> >>> >hoping > >>> >>> >>> >> >I > >>> >>> >>> >> >>> >>would > >>> >>> >>> >> >>> >>> >just > >>> >>> >>> >> >>> >>> >have a stream of bits to deal with on the > >pi/pc. > >>> >They > >>> >>> >say it > >>> >>> >>> >> >comes > >>> >>> >>> >> >>> >>> >with > >>> >>> >>> >> >>> >>> >example software to do this but it is within a > >>> >>> >commercial IDE > >>> >>> >>> >> >you > >>> >>> >>> >> >>> >>have > >>> >>> >>> >> >>> >>> >to > >>> >>> >>> >> >>> >>> >pay for. It has a free trial so hopefully that > >will > >>> >give > >>> >>> >me > >>> >>> >>> >> >enough > >>> >>> >>> >> >>> >>time > >>> >>> >>> >> >>> >>> >to > >>> >>> >>> >> >>> >>> >get it working. > >>> >>> >>> >> >>> >>> > > >>> >>> >>> >> >>> >>> >On Thu, 26 Jan 2023 at 14:32, Peter Price > >>> >***@***.*** > >>> >>> ><mailto:***@***.***> > >>> >>> >>> > wrote: > >>> >>> >>> >> >>> >>> > > >>> >>> >>> >> >>> >>> >> Good luck with that :-) > >>> >>> >>> >> >>> >>> >> > >>> >>> >>> >> >>> >>> >> The code has a lot of atmega specific code > >for > >>> >the > >>> >>> >hardware > >>> >>> >>> >> >>> >>> >interface. > >>> >>> >>> >> >>> >>> >> Because of the overhead the code doesn't use > >the > >>> >>> >Arduino IO > >>> >>> >>> >> >>> >>functions > >>> >>> >>> >> >>> >>> >but > >>> >>> >>> >> >>> >>> >> drives the GPIO pins directly via the > >registers. > >>> >>> >>> >> >>> >>> >> > >>> >>> >>> >> >>> >>> >> TX uses the SPI interface to fill the cc1101 > >TX > >>> >fifo, > >>> >>> >but, > >>> >>> >>> >> >>> >because > >>> >>> >>> >> >>> >>of > >>> >>> >>> >> >>> >>> >the > >>> >>> >>> >> >>> >>> >> jitter on the incoming signals from the other > >>> >devices, > >>> >>> >you > >>> >>> >>> >> >can't > >>> >>> >>> >> >>> >>use > >>> >>> >>> >> >>> >>> >the > >>> >>> >>> >> >>> >>> >> cc1101 rx fifo to capture the data because it > >>> >assumes > >>> >>> >>> >> >everything > >>> >>> >>> >> >>> >>is > >>> >>> >>> >> >>> >>> >> synchronous. > >>> >>> >>> >> >>> >>> >> > >>> >>> >>> >> >>> >>> >> If you try a port then I suggest you get the > >SPI > >>> >>> >interface > >>> >>> >>> to > >>> >>> >>> >> >the > >>> >>> >>> >> >>> >>> >CC1101 > >>> >>> >>> >> >>> >>> >> working first and then the HW UART interface > >>> >between > >>> >>> >the STM > >>> >>> >>> >> >and > >>> >>> >>> >> >>> >>the > >>> >>> >>> >> >>> >>> >> CC1101. This is just an ISR triggered by the > >UART > >>> >that > >>> >>> >reads > >>> >>> >>> >> >the > >>> >>> >>> >> >>> >>UART > >>> >>> >>> >> >>> >>> >RX > >>> >>> >>> >> >>> >>> >> data into a buffer. > >>> >>> >>> >> >>> >>> >> > >>> >>> >>> >> >>> >>> >> If the STM hasn't got a HW UART available > >then > >>> >you'll > >>> >>> >need > >>> >>> >>> to > >>> >>> >>> >> >be > >>> >>> >>> >> >>> >>good > >>> >>> >>> >> >>> >>> >at > >>> >>> >>> >> >>> >>> >> coding. I suspect the STM8 HW UART has been > >>> >connected > >>> >>> >to the > >>> >>> >>> >> >host > >>> >>> >>> >> >>> >>> >USB > >>> >>> >>> >> >>> >>> >> interface so this is going to be the case. > >>> >>> >>> >> >>> >>> >> > >>> >>> >>> >> >>> >>> >> The atmega328p SW UART code uses a HW > >interrupt > >>> >to > >>> >>> >capture > >>> >>> >>> >> >the > >>> >>> >>> >> >>> >>timing > >>> >>> >>> >> >>> >>> >of > >>> >>> >>> >> >>> >>> >> the signal edges and then a SW trap to > >process > >>> >the > >>> >>> >captured > >>> >>> >>> >> >data > >>> >>> >>> >> >>> >>> >edges to > >>> >>> >>> >> >>> >>> >> generate an RX byte. This is very processor > >heavy > >>> >and > >>> >>> >every > >>> >>> >>> >> >cycle > >>> >>> >>> >> >>> >>is > >>> >>> >>> >> >>> >>> >> critical to keep up with the data when it > >arrives. > >>> >The > >>> >>> >SW > >>> >>> >>> >> >UART > >>> >>> >>> >> >>> >>won't > >>> >>> >>> >> >>> >>> >work > >>> >>> >>> >> >>> >>> >> on an atmega clocked at less than 16MHz > >because > >>> >there > >>> >>> >aren't > >>> >>> >>> >> >>> >>enough > >>> >>> >>> >> >>> >>> >> instruction cycles available. > >>> >>> >>> >> >>> >>> >> > >>> >>> >>> >> >>> >>> >> The SW UART code is not as good at RXing > >radio > >>> >>> >messages as > >>> >>> >>> >> >the HW > >>> >>> >>> >> >>> >>> >UART > >>> >>> >>> >> >>> >>> >> code. > >>> >>> >>> >> >>> >>> >> > >>> >>> >>> >> >>> >>> >> Using a simple USB logic analyser ( e.g. > >>> >>> >>> >> >>> >>> >> > >>> >>> >>> >> >>> >>> > > >>> >>> >>> >> >>> >>> > >>> >>> >>> >> >>> >> > >>> >>> >>> >> >>> > >>> >>> >>> >> > > >>> >>> >>> >> > >>> >>> >>> > >>> >>> > > >>> >>> > >>> > > >>> > > > https://www.amazon.co.uk/Hobby-Components-24MHz-Analyser-1-1-16/dp/B00DAYAREW > >>> >>> >>> >> >>> >>> ) > >>> >>> >>> >> >>> >>> >> there are some debug lines still in the code > >that > >>> >you > >>> >>> >can > >>> >>> >>> use > >>> >>> >>> >> >to > >>> >>> >>> >> >>> >>> >drive > >>> >>> >>> >> >>> >>> >> spare GPIO pins that will show you how much > >>> >processor > >>> >>> >time > >>> >>> >>> >> >you're > >>> >>> >>> >> >>> >>> >using in > >>> >>> >>> >> >>> >>> >> the HW and SW ISR functions. > >>> >>> >>> >> >>> >>> >> > >>> >>> >>> >> >>> >>> >> The frame, message and host interface code > >should > >>> >>> >work > >>> >>> >>> >> >without > >>> >>> >>> >> >>> >>> >significant > >>> >>> >>> >> >>> >>> >> changes. > >>> >>> >>> >> >>> >>> >> > >>> >>> >>> >> >>> >>> >> That's all the help I can offer since I have > >zero > >>> >STM > >>> >>> >>> >> >knowledge. > >>> >>> >>> >> >>> >>> >> > >>> >>> >>> >> >>> >>> >> If you don't understand what I've said above > >give > >>> >up > >>> >>> >now. > >>> >>> >>> >> >>> >>> >> > >>> >>> >>> >> >>> >>> >> — > >>> >>> >>> >> >>> >>> >> Reply to this email directly, view it on > >GitHub > >>> >>> >>> >> >>> >>> >> > >>> >>> >>> >> >>> >>> > >>> >>> >>> >> >>> > >>> >>> >>> >> >>>>< > >>> >>> >>> > >>> > >>#35 (comment) > >>> >>> >< > >>> >>> >>> > >>> > >>#35 (comment) > >>> >>> >> > >>> >>> >>> >> >, > >>> >>> >>> >> >>> >>> >or > >>> >>> >>> >> >>> >>> >> unsubscribe > >>> >>> >>> >> >>> >>> >> > >>> >>> >>> >> >>> >>> >< > >>> >>> >>> >> >>> >>> > >>> >>> >>> >> >>> >> > >>> >>> >>> >> >>> > >>> >>> >>> >> > > >>> >>> >>> >> > >>> >>> >>> > >>> >>> > > >>> >>> > >>> > > >>> > > > https://github.com/notifications/unsubscribe-auth/AN4GHPSSWORQMO6CGL6XQV3WUKDJNANCNFSM6AAAAAAUHJSYXI > >>> >>> >>> >> >>> >>> > > >>> >>> >>> >> >>> >>> >> . > >>> >>> >>> >> >>> >>> >> You are receiving this because you authored > >the > >>> >>> >>> >> >thread.Message > >>> >>> >>> >> >>> >>ID: > >>> >>> >>> >> >>> >>> >> ***@***.*** <mailto:***@***.***> > > >>> >>> >>> >> >>> >>> >> > >>> >>> >>> >> >>> >>> > > >>> >>> >>> >> >>> >>> > > >>> >>> >>> >> >>> >>> >-- > >>> >>> >>> >> >>> >>> >Reply to this email directly or view it on > >GitHub: > >>> >>> >>> >> >>> >>> > >>> >>> >>> >> > >>> >>> > >>> > >>>>>#35 (comment) > >>> >>> >>> >> >>> >>> >You are receiving this because you commented. > >>> >>> >>> >> >>> >>> > > >>> >>> >>> >> >>> >>> >Message ID: ***@***.*** <mailto:***@***.***> > > >>> >>> >>> >> >>> >>> > >>> >>> >>> >> >>> >>> — > >>> >>> >>> >> >>> >>> Reply to this email directly, view it on GitHub > >>> >>> >>> >> >>> >>> > >>> >>> >>> >> >>> > >>> >>> >>> >> >>>< > >>> >>> >>> > >>> >>> > >>> > >>>#35 (comment)>, > >>> >>> >>> >> >>> >>or > >>> >>> >>> >> >>> >>> unsubscribe > >>> >>> >>> >> >>> >>> > >>> >>> >>> >> >>> >>< > >>> >>> >>> >> >>> > >>> >>> >>> >> > > >>> >>> >>> >> > >>> >>> >>> > >>> >>> > > >>> >>> > >>> > > >>> > > > https://github.com/notifications/unsubscribe-auth/AN4GHPWOTGSC3DO2F7TN4M3WUK6FHANCNFSM6AAAAAAUHJSYXI > >>> >>> >>> >> >>> > > >>> >>> >>> >> >>> >>> . > >>> >>> >>> >> >>> >>> You are receiving this because you authored the > >>> >>> >thread.Message > >>> >>> >>> >> >ID: > >>> >>> >>> >> >>> >>> ***@***.*** <mailto:***@***.***> > > >>> >>> >>> >> >>> >>> > >>> >>> >>> >> >>> >> > >>> >>> >>> >> >>> >> > >>> >>> >>> >> >>> >>-- > >>> >>> >>> >> >>> >>Reply to this email directly or view it on GitHub: > >>> >>> >>> >> >>> > >>> >>> >>> >> > >>> >>> > >>> > >>>>>>#35 (comment) > >>> >>> >>> >> >>> >>You are receiving this because you commented. > >>> >>> >>> >> >>> >> > >>> >>> >>> >> >>> >>Message ID: ***@***.*** <mailto:***@***.***> > > >>> >>> >>> >> >>> > >>> >>> >>> >> >>> — > >>> >>> >>> >> >>> Reply to this email directly, view it on GitHub > >>> >>> >>> >> >>> > >>> >>> >>> >> > >>> >>> > >>> > >>>><#35 (comment) > >>> >>> >>> >, > >>> >>> >>> >> >>> or unsubscribe > >>> >>> >>> >> >>> > >>> >>> >>> >> >< > >>> >>> >>> >> > >>> >>> >>> > >>> >>> > > >>> >>> > >>> > > >>> > > > https://github.com/notifications/unsubscribe-auth/AN4GHPWDEQVBRFCQWOYLZOLWULYNPANCNFSM6AAAAAAUHJSYXI > >>> >>> >>> >> > > >>> >>> >>> >> >>> . > >>> >>> >>> >> >>> You are receiving this because you authored the > >>> >>> >thread.Message ID: > >>> >>> >>> >> >>> ***@***.*** <mailto:***@***.***> > > >>> >>> >>> >> >>> > >>> >>> >>> >> >> > >>> >>> >>> >> > > >>> >>> >>> >> > > >>> >>> >>> >> >-- > >>> >>> >>> >> >Reply to this email directly or view it on GitHub: > >>> >>> >>> >> > >>> >>> > >>> > >>>>#35 (comment) > >>> >>> >>> >> >You are receiving this because you commented. > >>> >>> >>> >> > > >>> >>> >>> >> >Message ID: ***@***.*** <mailto:***@***.***> > > >>> >>> >>> >> > >>> >>> >>> >> — > >>> >>> >>> >> Reply to this email directly, view it on GitHub > >>> >>> >>> >> > >>> >>> > >>> > >>><#35 (comment)>, > >>> >>> >>> >> or unsubscribe > >>> >>> >>> >> < > >>> >>> >>> > >>> >>> > > >>> >>> > >>> > > >>> > > > https://github.com/notifications/unsubscribe-auth/AN4GHPWNBGQWDHVC25NK6GLWUVN2ZANCNFSM6AAAAAAUHJSYXI > >>> >>> >>> > > >>> >>> >>> >> . > >>> >>> >>> >> You are receiving this because you authored the > >>> >thread.Message > >>> >>> >ID: > >>> >>> >>> >> ***@***.*** <mailto:***@***.***> > > >>> >>> >>> >> > >>> >>> >>> > > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> — > >>> >>> >>> Reply to this email directly, view it on GitHub < > >>> >>> >>> > >>> > >>#35 (comment)> > >>> >>> >, > >>> >>> >>> or unsubscribe < > >>> >>> >>> > >>> >>> > > >>> >>> > >>> > > >>> > > > https://github.com/notifications/unsubscribe-auth/AIRU2WZ6QZ2JTH4S7JDX2OLWU2QWFANCNFSM6AAAAAAUHJSYXI > >>> >>> > > >>> >>> >>> . > >>> >>> >>> You are receiving this because you commented. < > >>> >>> >>> > >>> >>> > > >>> >>> > >>> > > >>> > > > https://github.com/notifications/beacon/AIRU2W6ZSCHUD2NWHFVREOTWU2QWFA5CNFSM6AAAAAAUHJSYXKWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTST5ANTO.gif > >>> >>> > > >>> >>> >>> Message ID: < ***@***.***> ***@***.***> > >>> >>> >>> > >>> >>> >>> — > >>> >>> >>> Reply to this email directly, view it on GitHub > >>> >>> >>> > >>> >>> > >>> > >>><#35 (comment)>, > >>> >>> >>> or unsubscribe > >>> >>> >>> > >>> >>> >< > >>> >>> > >>> > > >>> > > > https://github.com/notifications/unsubscribe-auth/AN4GHPWVQWX2H6DMZ7ZWXZTWU3B2XANCNFSM6AAAAAAUHJSYXI > >>> >>> > > >>> >>> >>> . > >>> >>> >>> You are receiving this because you authored the > >thread.Message > >>> >ID: > >>> >>> >>> ***@***.***> > >>> >>> >>> > >>> >>> >> > >>> >>> > > >>> >>> > > >>> >>> >-- > >>> >>> >Reply to this email directly or view it on GitHub: > >>> >>> > >>> > >>>#35 (comment) > >>> >>> >You are receiving this because you commented. > >>> >>> > > >>> >>> >Message ID: ***@***.***> > >>> >>> > >>> >>> — > >>> >>> Reply to this email directly, view it on GitHub > >>> >>> > >>> > >><#35 (comment)>, > >>> >>> or unsubscribe > >>> >>> > >>> >< > >>> > > > https://github.com/notifications/unsubscribe-auth/AN4GHPQ66E3C37NVCBNLY4LWVGGSVANCNFSM6AAAAAAUHJSYXI > >>> > > >>> >>> . > >>> >>> You are receiving this because you authored the thread.Message > >ID: > >>> >>> ***@***.***> > >>> >>> > >>> >> > >>> > > >>> > > >>> >-- > >>> >Reply to this email directly or view it on GitHub: > >>> > >>#35 (comment) > >>> >You are receiving this because you commented. > >>> > > >>> >Message ID: ***@***.***> > >>> > >>> — > >>> Reply to this email directly, view it on GitHub > >>> > ><#35 (comment)>, > >>> or unsubscribe > >>> > >< > https://github.com/notifications/unsubscribe-auth/AN4GHPTQPA4ZFLA47AKROBTWVKRLRANCNFSM6AAAAAAUHJSYXI > > > >>> . > >>> You are receiving this because you authored the thread.Message ID: > >>> ***@***.***> > >>> > >> > > > > > >-- > >Reply to this email directly or view it on GitHub: > >#35 (comment) > >You are receiving this because you commented. > > > >Message ID: ***@***.***> > > — > Reply to this email directly, view it on GitHub > <#35 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AN4GHPXDWJKR23KS45BMOT3WV6C2FANCNFSM6AAAAAAUHJSYXI> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

On Mon, 13 Feb 2023, 15:54 Peter Price, ***@***.***> wrote: Glad you got it working. However, I’m not going to encourage you to share your success because I sell these :) < https://indalo-tech.onlineweb.shop/SSM-D2/p7844707_21584696.aspx> Although, I guess anyone with no soldering skills will prefer a pre-built module. FYI The green cc1101 module you’ve got comes with a lot of manufacturing variation and at least one source has supplied modules with inaccurate 26MHz crystals – the original reason for autotune. Also your module uses an atmega328p rather than the recommended atmega32u4. While evofw3 is better than any other firmware at detecting messages successfully with this processor using a SW UART it’s still not as good as using a HW UART. Peter From: pdbayes ***@***.*** Sent: 13 February 2023 10:18 To: ghoti57/evofw3 ***@***.***> Cc: Peter Price ***@***.***>; Comment ***@***.***> Subject: Re: [ghoti57/evofw3] STM8 (Issue #35) Hi. The device I got worked perfectly. You do need a reasonably good soldering station and good eyesight, magnifier. I used to rework SMD chips for a living but my eyesight is not what it used to be, but managed to do it. Thanks for all your help. I can recommend the kit I ordered as the service was good and they sent a booklet on assembly and preloaded the firmware. I would advise anyone avoid eBay sellers claiming to cover all frequency bands. I had to explain the regulations, technicalities etc to the seller who insulted my knowledge and claimed he wasn't selling what turned out to be an ebyte 433mhz module but he was selling a CC1101. He couldn't understand that once in a circuit the circuit is what needs to be tested and approved. I also did RG approvals in a lab for a few years and he still wouldn't have it. Luckily eBay stepped in and refunded. — Reply to this email directly, view it on GitHub < #35 (comment)> , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AIRU2W4CWHM7JFSUNKQNTATWXIC5PANCNFSM6AAAAAAUHJSYXI> . You are receiving this because you commented. < https://github.com/notifications/beacon/AIRU2W25RALNLMICFFRTSCDWXIC5PA5CNFSM6AAAAAAUHJSYXKWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSVDCWDE.gif> Message ID: ***@***.*** ***@***.***> > — Reply to this email directly, view it on GitHub <#35 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AN4GHPXMVOAUE3UUHOLKYC3WXJKKZANCNFSM6AAAAAAUHJSYXI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

On 13 Feb 2023, 19:15, at 19:15, pdbayes ***@***.***> wrote: I did look at yours but they were out of stock when I looked. Feel free to delete the post. It seems to be working fine for my needs. I have a current sensor monitoring the pump and we know the volume per minute through the jet as we needed a better early to monitor oil usage. I want to be able to change the boiler thermostat so that when it's heating only I can drop the temperature as it never goes into condensing mode as at 70 the return is too hot. I will have designed a whole new boiler control at this rate. My father in law was a technical director of a boiler company and has patents on boiler design but I seem more interested in making it work better. Oil boilers are not great. On Mon, 13 Feb 2023, 15:54 Peter Price, ***@***.***> wrote: > Glad you got it working. > > > > However, I’m not going to encourage you to share your success because I > sell these :) > < https://indalo-tech.onlineweb.shop/SSM-D2/p7844707_21584696.aspx> > > > > Although, I guess anyone with no soldering skills will prefer a pre-built > module. > > > > FYI > > The green cc1101 module you’ve got comes with a lot of manufacturing > variation and at least one source has supplied modules with inaccurate > 26MHz crystals – the original reason for autotune. > > Also your module uses an atmega328p rather than the recommended > atmega32u4. > > While evofw3 is better than any other firmware at detecting messages > successfully with this processor using a SW UART it’s still not as good as > using a HW UART. > > > > Peter > > > > From: pdbayes ***@***.*** > Sent: 13 February 2023 10:18 > To: ghoti57/evofw3 ***@***.***> > Cc: Peter Price ***@***.***>; Comment ***@***.***> > Subject: Re: [ghoti57/evofw3] STM8 (Issue #35) > > > > Hi. The device I got worked perfectly. You do need a reasonably good > soldering station and good eyesight, magnifier. I used to rework SMD chips > for a living but my eyesight is not what it used to be, but managed to do > it. Thanks for all your help. I can recommend the kit I ordered as the > service was good and they sent a booklet on assembly and preloaded the > firmware. I would advise anyone avoid eBay sellers claiming to cover all > frequency bands. I had to explain the regulations, technicalities etc to > the seller who insulted my knowledge and claimed he wasn't selling what > turned out to be an ebyte 433mhz module but he was selling a CC1101. He > couldn't understand that once in a circuit the circuit is what needs to be > tested and approved. I also did RG approvals in a lab for a few years and > he still wouldn't have it. Luckily eBay stepped in and refunded. > > — > Reply to this email directly, view it on GitHub < > #35 (comment)> , or > unsubscribe < > https://github.com/notifications/unsubscribe-auth/AIRU2W4CWHM7JFSUNKQNTATWXIC5PANCNFSM6AAAAAAUHJSYXI> > . > You are receiving this because you commented. < > https://github.com/notifications/beacon/AIRU2W25RALNLMICFFRTSCDWXIC5PA5CNFSM6AAAAAAUHJSYXKWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSVDCWDE.gif> > Message ID: ***@***.*** ***@***.***> > > > — > Reply to this email directly, view it on GitHub > <#35 (comment)>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AN4GHPXMVOAUE3UUHOLKYC3WXJKKZANCNFSM6AAAAAAUHJSYXI> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> > -- Reply to this email directly or view it on GitHub: #35 (comment) You are receiving this because you commented. Message ID: ***@***.***>

On Mon, 13 Feb 2023, 19:36 Peter Price, ***@***.***> wrote: It might be worth while looking at opentherm controllers to see if you can get any hints. ⁣Get BlueMail for Android ​ On 13 Feb 2023, 19:15, at 19:15, pdbayes ***@***.***> wrote: >I did look at yours but they were out of stock when I looked. Feel free >to >delete the post. It seems to be working fine for my needs. I have a >current sensor monitoring the pump and we know the volume per minute >through the jet as we needed a better early to monitor oil usage. I >want to >be able to change the boiler thermostat so that when it's heating only >I >can drop the temperature as it never goes into condensing mode as at 70 >the >return is too hot. I will have designed a whole new boiler control at >this >rate. My father in law was a technical director of a boiler company and >has >patents on boiler design but I seem more interested in making it work >better. Oil boilers are not great. > >On Mon, 13 Feb 2023, 15:54 Peter Price, ***@***.***> wrote: > >> Glad you got it working. >> >> >> >> However, I’m not going to encourage you to share your success because >I >> sell these :) >> < https://indalo-tech.onlineweb.shop/SSM-D2/p7844707_21584696.aspx> >> >> >> >> Although, I guess anyone with no soldering skills will prefer a >pre-built >> module. >> >> >> >> FYI >> >> The green cc1101 module you’ve got comes with a lot of manufacturing >> variation and at least one source has supplied modules with >inaccurate >> 26MHz crystals – the original reason for autotune. >> >> Also your module uses an atmega328p rather than the recommended >> atmega32u4. >> >> While evofw3 is better than any other firmware at detecting messages >> successfully with this processor using a SW UART it’s still not as >good as >> using a HW UART. >> >> >> >> Peter >> >> >> >> From: pdbayes ***@***.*** >> Sent: 13 February 2023 10:18 >> To: ghoti57/evofw3 ***@***.***> >> Cc: Peter Price ***@***.***>; Comment ***@***.***> >> Subject: Re: [ghoti57/evofw3] STM8 (Issue #35) >> >> >> >> Hi. The device I got worked perfectly. You do need a reasonably good >> soldering station and good eyesight, magnifier. I used to rework SMD >chips >> for a living but my eyesight is not what it used to be, but managed >to do >> it. Thanks for all your help. I can recommend the kit I ordered as >the >> service was good and they sent a booklet on assembly and preloaded >the >> firmware. I would advise anyone avoid eBay sellers claiming to cover >all >> frequency bands. I had to explain the regulations, technicalities etc >to >> the seller who insulted my knowledge and claimed he wasn't selling >what >> turned out to be an ebyte 433mhz module but he was selling a CC1101. >He >> couldn't understand that once in a circuit the circuit is what needs >to be >> tested and approved. I also did RG approvals in a lab for a few years >and >> he still wouldn't have it. Luckily eBay stepped in and refunded. >> >> — >> Reply to this email directly, view it on GitHub < >> #35 (comment)> >, or >> unsubscribe < >> > https://github.com/notifications/unsubscribe-auth/AIRU2W4CWHM7JFSUNKQNTATWXIC5PANCNFSM6AAAAAAUHJSYXI > >> . >> You are receiving this because you commented. < >> > https://github.com/notifications/beacon/AIRU2W25RALNLMICFFRTSCDWXIC5PA5CNFSM6AAAAAAUHJSYXKWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSVDCWDE.gif > >> Message ID: ***@***.*** ***@***.***> > >> >> — >> Reply to this email directly, view it on GitHub >> ><#35 (comment)>, >or >> unsubscribe >> >< https://github.com/notifications/unsubscribe-auth/AN4GHPXMVOAUE3UUHOLKYC3WXJKKZANCNFSM6AAAAAAUHJSYXI > >> . >> You are receiving this because you authored the thread.Message ID: >> ***@***.***> >> > > >-- >Reply to this email directly or view it on GitHub: >#35 (comment) >You are receiving this because you commented. > >Message ID: ***@***.***> — Reply to this email directly, view it on GitHub <#35 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AN4GHPXHS4D3CXE2GRKQJXTWXKENVANCNFSM6AAAAAAUHJSYXI> . You are receiving this because you authored the thread.Message ID: ***@***.***>