STM8

[pdbayes]

Hi I have the Ebyte E07 dev board with uart. The processor is an stm8, does anyone know how to port this code for an STM8?

[ghoti57]

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.

[pdbayes]

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 https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405090960, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN4GHPSSWORQMO6CGL6XQV3WUKDJNANCNFSM6AAAAAAUHJSYXI . You are receiving this because you authored the thread.Message ID: @.***>

[ghoti57]

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

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405090960, 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: https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405144774 You are receiving this because you commented.

Message ID: @.***>

[pdbayes]

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

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405090960, 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: https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405144774 You are receiving this because you commented.

Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405416686, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN4GHPWOTGSC3DO2F7TN4M3WUK6FHANCNFSM6AAAAAAUHJSYXI . You are receiving this because you authored the thread.Message ID: @.***>

[ghoti57]

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

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405090960,

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: https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405144774 You are receiving this because you commented.

Message ID: @.***>

— Reply to this email directly, view it on GitHub

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405416686, 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: https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405570504 You are receiving this because you commented.

Message ID: @.***>

[ghoti57]

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

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405090960,

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: https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405144774 You are receiving this because you commented.

Message ID: @.***>

— Reply to this email directly, view it on GitHub

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405416686, 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: https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405570504 You are receiving this because you commented.

Message ID: @.***>

[pdbayes]

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

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405090960,

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: https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405144774 You are receiving this because you commented.

Message ID: @.***>

— Reply to this email directly, view it on GitHub

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405416686, 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: https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405570504 You are receiving this because you commented.

Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405733009, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN4GHPWDEQVBRFCQWOYLZOLWULYNPANCNFSM6AAAAAAUHJSYXI . You are receiving this because you authored the thread.Message ID: @.***>

[pdbayes]

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

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405090960,

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: https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405144774 You are receiving this because you commented.

Message ID: @.***>

— Reply to this email directly, view it on GitHub

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405416686, 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: https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405570504 You are receiving this because you commented.

Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405733009, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN4GHPWDEQVBRFCQWOYLZOLWULYNPANCNFSM6AAAAAAUHJSYXI . You are receiving this because you authored the thread.Message ID: @.***>

[ghoti57]

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

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405090960,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405144774

You are receiving this because you commented.

Message ID: @.***>

— Reply to this email directly, view it on GitHub

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405416686,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405570504

You are receiving this because you commented.

Message ID: @.***>

— Reply to this email directly, view it on GitHub

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405733009, 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: https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407429571 You are receiving this because you commented.

Message ID: @.***>

[pdbayes]

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

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405090960,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405144774

You are receiving this because you commented.

Message ID: @.***>

— Reply to this email directly, view it on GitHub

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405416686,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405570504

You are receiving this because you commented.

Message ID: @.***>

— Reply to this email directly, view it on GitHub

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405733009, 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: https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407429571 You are receiving this because you commented.

Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407454080, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN4GHPWNBGQWDHVC25NK6GLWUVN2ZANCNFSM6AAAAAAUHJSYXI . You are receiving this because you authored the thread.Message ID: @.***>

[pdbayes]

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, @.***> 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

<https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405090960 ,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405144774

You are receiving this because you commented.

Message ID: @.***>

— Reply to this email directly, view it on GitHub

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405416686,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405570504

You are receiving this because you commented.

Message ID: @.***>

— Reply to this email directly, view it on GitHub

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405733009, 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: https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407429571 You are receiving this because you commented.

Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407454080, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN4GHPWNBGQWDHVC25NK6GLWUVN2ZANCNFSM6AAAAAAUHJSYXI . You are receiving this because you authored the thread.Message ID: @.***>

[ghoti57]

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

[pdbayes]

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

< https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405090960 < https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405090960 > ,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405144774

You are receiving this because you commented.

Message ID: @. <mailto:@.> >

— Reply to this email directly, view it on GitHub

<https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405416686 ,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405570504

You are receiving this because you commented.

Message ID: @. <mailto:@.> >

— Reply to this email directly, view it on GitHub

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405733009, 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: https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407429571 You are receiving this because you commented.

Message ID: @. <mailto:@.> >

— Reply to this email directly, view it on GitHub https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407454080, 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 < https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407720247> , 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 https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407752577, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN4GHPWVQWX2H6DMZ7ZWXZTWU3B2XANCNFSM6AAAAAAUHJSYXI . You are receiving this because you authored the thread.Message ID: @.***>

[pdbayes]

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:

[ghoti57]

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 ​

[pdbayes]

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

< https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405090960 < https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405090960

,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405144774

You are receiving this because you commented.

Message ID: @. <mailto:@.> >

— Reply to this email directly, view it on GitHub

<

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405416686>,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405570504

You are receiving this because you commented.

Message ID: @. <mailto:@.> >

— Reply to this email directly, view it on GitHub

<https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405733009 ,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407429571

You are receiving this because you commented.

Message ID: @. <mailto:@.> >

— Reply to this email directly, view it on GitHub

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407454080, 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 < https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407720247> , 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

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407752577, 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: https://github.com/ghoti57/evofw3/issues/35#issuecomment-1411068308 You are receiving this because you commented.

Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/ghoti57/evofw3/issues/35#issuecomment-1411153030, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN4GHPQ66E3C37NVCBNLY4LWVGGSVANCNFSM6AAAAAAUHJSYXI . You are receiving this because you authored the thread.Message ID: @.***>

[pdbayes]

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

< https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405090960 < https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405090960

,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405144774

You are receiving this because you commented.

Message ID: @. <mailto:@.> >

— Reply to this email directly, view it on GitHub

<

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405416686>,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405570504

You are receiving this because you commented.

Message ID: @. <mailto:@.> >

— Reply to this email directly, view it on GitHub

<https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405733009 ,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407429571

You are receiving this because you commented.

Message ID: @. <mailto:@.> >

— Reply to this email directly, view it on GitHub

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407454080, 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 < https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407720247> , 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

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407752577, 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: https://github.com/ghoti57/evofw3/issues/35#issuecomment-1411068308 You are receiving this because you commented.

Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/ghoti57/evofw3/issues/35#issuecomment-1411153030, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN4GHPQ66E3C37NVCBNLY4LWVGGSVANCNFSM6AAAAAAUHJSYXI . You are receiving this because you authored the thread.Message ID: @.***>

[ghoti57]

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

<

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405090960 <

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405090960

,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405144774

You are receiving this because you commented.

Message ID: @. <mailto:@.> >

— Reply to this email directly, view it on GitHub

<

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405416686>,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405570504

You are receiving this because you commented.

Message ID: @. <mailto:@.> >

— Reply to this email directly, view it on GitHub

<https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405733009

,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407429571

You are receiving this because you commented.

Message ID: @. <mailto:@.> >

— Reply to this email directly, view it on GitHub

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407454080,

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 <

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407720247> , 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

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407752577,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1411068308

You are receiving this because you commented.

Message ID: @.***>

— Reply to this email directly, view it on GitHub

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1411153030, 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: https://github.com/ghoti57/evofw3/issues/35#issuecomment-1411639251 You are receiving this because you commented.

Message ID: @.***>

[pdbayes]

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

<

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405090960 <

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405090960

,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405144774

You are receiving this because you commented.

Message ID: @. <mailto:@.> >

— Reply to this email directly, view it on GitHub

<

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405416686>,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405570504

You are receiving this because you commented.

Message ID: @. <mailto:@.> >

— Reply to this email directly, view it on GitHub

<https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405733009

,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407429571

You are receiving this because you commented.

Message ID: @. <mailto:@.> >

— Reply to this email directly, view it on GitHub

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407454080,

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 <

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407720247> , 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

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407752577,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1411068308

You are receiving this because you commented.

Message ID: @.***>

— Reply to this email directly, view it on GitHub

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1411153030, 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: https://github.com/ghoti57/evofw3/issues/35#issuecomment-1411639251 You are receiving this because you commented.

Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/ghoti57/evofw3/issues/35#issuecomment-1412506410, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN4GHPTQPA4ZFLA47AKROBTWVKRLRANCNFSM6AAAAAAUHJSYXI . You are receiving this because you authored the thread.Message ID: @.***>

[pdbayes]

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

<

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405090960 <

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405090960

,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405144774

You are receiving this because you commented.

Message ID: @. <mailto:@.> >

— Reply to this email directly, view it on GitHub

<

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405416686>,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405570504

You are receiving this because you commented.

Message ID: @. <mailto:@.> >

— Reply to this email directly, view it on GitHub

<https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405733009

,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407429571

You are receiving this because you commented.

Message ID: @. <mailto:@.> >

— Reply to this email directly, view it on GitHub

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407454080,

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 <

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407720247> , 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

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407752577,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1411068308

You are receiving this because you commented.

Message ID: @.***>

— Reply to this email directly, view it on GitHub

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1411153030, 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: https://github.com/ghoti57/evofw3/issues/35#issuecomment-1411639251 You are receiving this because you commented.

Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/ghoti57/evofw3/issues/35#issuecomment-1412506410, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN4GHPTQPA4ZFLA47AKROBTWVKRLRANCNFSM6AAAAAAUHJSYXI . You are receiving this because you authored the thread.Message ID: @.***>

[ghoti57]

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

<

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405090960

<

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405090960

,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405144774

You are receiving this because you commented.

Message ID: @. <mailto:@.> >

— Reply to this email directly, view it on GitHub

<

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405416686>,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405570504

You are receiving this because you commented.

Message ID: @. <mailto:@.> >

— Reply to this email directly, view it on GitHub

<https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405733009

,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407429571

You are receiving this because you commented.

Message ID: @. <mailto:@.> >

— Reply to this email directly, view it on GitHub

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407454080,

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 <

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407720247>

,

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

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407752577,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1411068308

You are receiving this because you commented.

Message ID: @.***>

— Reply to this email directly, view it on GitHub

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1411153030,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1411639251

You are receiving this because you commented.

Message ID: @.***>

— Reply to this email directly, view it on GitHub

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1412506410, 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: https://github.com/ghoti57/evofw3/issues/35#issuecomment-1417250676 You are receiving this because you commented.

Message ID: @.***>

[pdbayes]

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

<

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405090960

<

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405090960

,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405144774

You are receiving this because you commented.

Message ID: @. <mailto:@.> >

— Reply to this email directly, view it on GitHub

<

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405416686>,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405570504

You are receiving this because you commented.

Message ID: @. <mailto:@.> >

— Reply to this email directly, view it on GitHub

<https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405733009

,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407429571

You are receiving this because you commented.

Message ID: @. <mailto:@.> >

— Reply to this email directly, view it on GitHub

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407454080,

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 <

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407720247>

,

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

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407752577,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1411068308

You are receiving this because you commented.

Message ID: @.***>

— Reply to this email directly, view it on GitHub

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1411153030,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1411639251

You are receiving this because you commented.

Message ID: @.***>

— Reply to this email directly, view it on GitHub

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1412506410, 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: https://github.com/ghoti57/evofw3/issues/35#issuecomment-1417250676 You are receiving this because you commented.

Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/ghoti57/evofw3/issues/35#issuecomment-1417477286, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN4GHPXDWJKR23KS45BMOT3WV6C2FANCNFSM6AAAAAAUHJSYXI . You are receiving this because you authored the thread.Message ID: @.***>

[pdbayes]

Fortunately also 16mhz so should be ok. Pretty much same spec as an Uno without the voltage regulator and as many gpio

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

<

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405090960

<

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405090960

,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405144774

You are receiving this because you commented.

Message ID: @. <mailto:@.> >

— Reply to this email directly, view it on GitHub

<

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405416686>,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405570504

You are receiving this because you commented.

Message ID: @. <mailto:@.> >

— Reply to this email directly, view it on GitHub

<https://github.com/ghoti57/evofw3/issues/35#issuecomment-1405733009

,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407429571

You are receiving this because you commented.

Message ID: @. <mailto:@.> >

— Reply to this email directly, view it on GitHub

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407454080,

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 <

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407720247>

,

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

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1407752577,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1411068308

You are receiving this because you commented.

Message ID: @.***>

— Reply to this email directly, view it on GitHub

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1411153030,

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:

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1411639251

You are receiving this because you commented.

Message ID: @.***>

— Reply to this email directly, view it on GitHub

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1412506410, 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: https://github.com/ghoti57/evofw3/issues/35#issuecomment-1417250676 You are receiving this because you commented.

Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/ghoti57/evofw3/issues/35#issuecomment-1417477286, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN4GHPXDWJKR23KS45BMOT3WV6C2FANCNFSM6AAAAAAUHJSYXI . You are receiving this because you authored the thread.Message ID: @.***>

[pdbayes]

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.

[ghoti57]

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

[pdbayes]

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 < https://github.com/ghoti57/evofw3/issues/35#issuecomment-1427680306> , 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 https://github.com/ghoti57/evofw3/issues/35#issuecomment-1428183234, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN4GHPXMVOAUE3UUHOLKYC3WXJKKZANCNFSM6AAAAAAUHJSYXI . You are receiving this because you authored the thread.Message ID: @.***>

[ghoti57]

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 < https://github.com/ghoti57/evofw3/issues/35#issuecomment-1427680306> , 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

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1428183234, 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: https://github.com/ghoti57/evofw3/issues/35#issuecomment-1428512862 You are receiving this because you commented.

Message ID: @.***>

[pdbayes]

Thanks. Shame Honeywell and opentherm don't play nice. Should be simple logic in principle, replace thermostat with a relay, clamp on thermistor on the out pipe, to measure temperature and if the DHW deman is more than 0 turn off at 70. Measure the return temp and turn off the boiler when the return gets to around 55.

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 < https://github.com/ghoti57/evofw3/issues/35#issuecomment-1427680306> , 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

https://github.com/ghoti57/evofw3/issues/35#issuecomment-1428183234, 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: https://github.com/ghoti57/evofw3/issues/35#issuecomment-1428512862 You are receiving this because you commented.

Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/ghoti57/evofw3/issues/35#issuecomment-1428544783, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN4GHPXHS4D3CXE2GRKQJXTWXKENVANCNFSM6AAAAAAUHJSYXI . You are receiving this because you authored the thread.Message ID: @.***>