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