[GH-ISSUE #427] AP Channel not properly changed / visualised #3017

New Issue

@Rudios81 commented on GitHub (Mar 20, 2025):

I don't 100% understand why it is unclear at what channel the tags are checking in, it clearly states CH25, right? Of am I misunderstanding the information on that page?
I did not change any setting since shortly after creating this issue notification and still now nothing has changed.
My AP is set to channel 15 in the config which is also showing on the AP status page like it did before.
After all this time (over 2 months without really touching the system) all my tags still show CH25 just as in the screenshots before.
How can I know for sure on which channel the tags are communicating?
To be clear, they are working, and in the end I do not really care what channel is in use, but I just wanted to make myself familiar with they way this channel works and came accross this potential issue.

@Rudios81 commented on GitHub (Mar 20, 2025): I don't 100% understand why it is unclear at what channel the tags are checking in, it clearly states CH25, right? Of am I misunderstanding the information on that page? I did not change any setting since shortly after creating this issue notification and still now nothing has changed. My AP is set to channel 15 in the config which is also showing on the AP status page like it did before. After all this time (over 2 months without really touching the system) all my tags still show CH25 just as in the screenshots before. How can I know for sure on which channel the tags are communicating? To be clear, they are working, and in the end I do not really care what channel is in use, but I just wanted to make myself familiar with they way this channel works and came accross this potential issue.

sascha_hemi commented

@nlimper commented on GitHub (Mar 20, 2025):

"it clearly states CH25" but it was not clear what the context was of that screenshots. By cropping important info away, it makes it hard to say what's going on.

To debug: check the serial output of the usb uart of your OEPL access point. You can use putty, or any other serial terminal software.
All tag communication appears there. Normally, there will be a stream of info like

I (1251660) RADIO: RX 42
I (1251660) RADIO: TX 41
I (1251670) RADIO: RX 42
I (1251670) RADIO: TX 41

that indicates that the tags are communicating.
Now, while leaving the serial output running, when you change the channel in the web interface, you will see something like

I (1153340) phy: libbtbb version: f97b181, May  8 2024, 10:42:29
I (1153640) RADIO: Receiver ready, panId=0x4447, channel=20, long=c4:8c:42:fe:ff:ca:4c:40, short=fffe
I (1153640) MAIN: Set channel: 20 power: 10

that indicates that the esp32-c6 has received the command and has set the channel. If all goes right, you will now see the tags communicating anymore, because they expect the AP on the former channel id. After a while (between 10-60 minutes) the tags will do a network scan, and will find the AP again on the new channel. From that point on, it should reflect on the tag info cards on the web interface.

@nlimper commented on GitHub (Mar 20, 2025): "it clearly states CH25" but it was not clear what the context was of that screenshots. By cropping important info away, it makes it hard to say what's going on. To debug: check the serial output of the usb uart of your OEPL access point. You can use putty, or any other serial terminal software. All tag communication appears there. Normally, there will be a stream of info like ``` I (1251660) RADIO: RX 42 I (1251660) RADIO: TX 41 I (1251670) RADIO: RX 42 I (1251670) RADIO: TX 41 ``` that indicates that the tags are communicating. Now, while leaving the serial output running, when you change the channel in the web interface, you will see something like ``` I (1153340) phy: libbtbb version: f97b181, May 8 2024, 10:42:29 I (1153640) RADIO: Receiver ready, panId=0x4447, channel=20, long=c4:8c:42:fe:ff:ca:4c:40, short=fffe I (1153640) MAIN: Set channel: 20 power: 10 ``` that indicates that the esp32-c6 has received the command and has set the channel. If all goes right, you will now see the tags communicating anymore, because they expect the AP on the former channel id. After a while (between 10-60 minutes) the tags will do a network scan, and will find the AP again on the new channel. From that point on, it should reflect on the tag info cards on the web interface.

sascha_hemi commented

@Rudios81 commented on GitHub (Mar 20, 2025):

@nlimper
Thanks for the quick reply, sorry for not sharing 100% clear screenshots.
I have tried your debugging suggestion.
When connecting, I indeed see those Radio TX/RX messages.
But when changing the Channel on the web-gui I do only see these lines:

I (257044) MAIN: SCP In
I (257264) MAIN: SCP In
I (257484) MAIN: SCP In
I (288064) MAIN: UART Timeout
I (288064) MAIN: RDY? In

And shortly after the Radio Tx/Rx messages continue to appear.
This gives me the indication that the AP is not properly changing channel, while this change is somehow saved on the backend of the web-gui

[Additional info]
When having the debug still running, and resetting the C6 board with the button I see the following log line coming through.
I (694) RADIO: Receiver ready, panId=0x4447, channel=25, long=b8:0e:4e:fe:ff:ca:4c:40, short=fffe
That reads it is using channel 25, and it stays like that, no matter what I change on the gui
Also tried re-flashing the C6 board, but that did not give any change in behaviour

@Rudios81 commented on GitHub (Mar 20, 2025): @nlimper Thanks for the quick reply, sorry for not sharing 100% clear screenshots. I have tried your debugging suggestion. When connecting, I indeed see those Radio TX/RX messages. But when changing the Channel on the web-gui I do only see these lines: ``` I (257044) MAIN: SCP In I (257264) MAIN: SCP In I (257484) MAIN: SCP In I (288064) MAIN: UART Timeout I (288064) MAIN: RDY? In ``` And shortly after the Radio Tx/Rx messages continue to appear. This gives me the indication that the AP is not properly changing channel, while this change is somehow saved on the backend of the web-gui [Additional info] When having the debug still running, and resetting the C6 board with the button I see the following log line coming through. `I (694) RADIO: Receiver ready, panId=0x4447, channel=25, long=b8:0e:4e:fe:ff:ca:4c:40, short=fffe` That reads it is using channel 25, and it stays like that, no matter what I change on the gui Also tried re-flashing the C6 board, but that did not give any change in behaviour

sascha_hemi commented

@nlimper commented on GitHub (Mar 20, 2025):

I'm not sure what happens there.
In the code of the ESP32-C6 I see a behaviour that's depending on if a subGHz module is present. But I'm not familiar with the C6 code.
https://github.com/OpenEPaperLink/AP_Radio_FW_ESP32/blob/master/OpenEPaperLink_esp32_C6_AP/main/main.c#L323-L364
Maybe @skiphansen knows more.

@nlimper commented on GitHub (Mar 20, 2025): I'm not sure what happens there. In the code of the ESP32-C6 I see a behaviour that's depending on if a subGHz module is present. But I'm not familiar with the C6 code. https://github.com/OpenEPaperLink/AP_Radio_FW_ESP32/blob/master/OpenEPaperLink_esp32_C6_AP/main/main.c#L323-L364 Maybe @skiphansen knows more.

sascha_hemi commented

@Rudios81 commented on GitHub (Mar 20, 2025):

That is strange, because the build I use (it's a custom build, based on Mini AP v4) has not enabled the subGHz option

@Rudios81 commented on GitHub (Mar 20, 2025): That is strange, because the build I use (it's a custom build, based on Mini AP v4) has not enabled the subGHz option

sascha_hemi commented

@nlimper commented on GitHub (Mar 20, 2025):

Good to know.

@nlimper commented on GitHub (Mar 20, 2025): Good to know.

sascha_hemi commented

@skiphansen commented on GitHub (Mar 20, 2025):

That is strange, because the build I use (it's a custom build, based on Mini AP v4) has not enabled the subGHz option

If this means you've built the C6 firmware yourself without after unsetting CONFIG_OEPL_SUBGIG_SUPPORT then that code is not present.

If you mean you don't have a subGhz module attached to your custom build then the dropdown box used to select the subGhz channel should not even be displayed in the GUI so the subGhz channel should not have changed and the if should be false.

Basically that code is figuring out if the channel being set is the 802.14.5 channel or the subGhz channel is being set so the appropriate radio can be reconfigured.

@skiphansen commented on GitHub (Mar 20, 2025): > That is strange, because the build I use (it's a custom build, based on Mini AP v4) has not enabled the subGHz option If this means you've built the C6 firmware yourself without after unsetting CONFIG_OEPL_SUBGIG_SUPPORT then that code is not present. If you mean you don't have a subGhz module attached to your custom build then the dropdown box used to select the subGhz channel should not even be displayed in the GUI so the subGhz channel should not have changed and the if should be false. Basically that code is figuring out if the channel being set is the 802.14.5 channel or the subGhz channel is being set so the appropriate radio can be reconfigured.

sascha_hemi commented

@Rudios81 commented on GitHub (Mar 20, 2025):

I did not build the C6 firmware myself, only the S3 AP side.
As far as know i do not have any subGHz module, neither is there any subGHz related setting on the web-gui.
But now reading more info about it I am getting confused.
Is this IEEE 802.15.4 to do with subGHz? I thought is was about the channel the AP and tags are communicating, and that subGHz is another way of communicating with a specific type of tages (obviously supporting subGHz) and requires an additional chip on the AP.
To be clear. I have a Lilygo T-Display-S3 https://lilygo.cc/products/t-display-s3
connected to an ESP-C6-DevKit-M1 devboard https://docs.espressif.com/projects/esp-dev-kits/en/latest/esp32c6/esp32-c6-devkitm-1/user_guide.html

@Rudios81 commented on GitHub (Mar 20, 2025): I did not build the C6 firmware myself, only the S3 AP side. As far as know i do not have any subGHz module, neither is there any subGHz related setting on the web-gui. But now reading more info about it I am getting confused. Is this IEEE 802.15.4 to do with subGHz? I thought is was about the channel the AP and tags are communicating, and that subGHz is another way of communicating with a specific type of tages (obviously supporting subGHz) and requires an additional chip on the AP. To be clear. I have a Lilygo T-Display-S3 [https://lilygo.cc/products/t-display-s3](url) connected to an ESP-C6-DevKit-M1 devboard [https://docs.espressif.com/projects/esp-dev-kits/en/latest/esp32c6/esp32-c6-devkitm-1/user_guide.html](url)

sascha_hemi commented

@nlimper commented on GitHub (Mar 20, 2025):

@Rudios81 Forget all mentions of SubGHz, it was just that I came across it in the channel select function in the C6 code.

@nlimper commented on GitHub (Mar 20, 2025): @Rudios81 Forget all mentions of SubGHz, it was just that I came across it in the channel select function in the C6 code.

sascha_hemi commented

@skiphansen commented on GitHub (Mar 20, 2025):

Please provide a complete capture of the serial log from power up until after you attempt to change the channel. That should tell us what's happening or at least give us more clues.
(just FYI: files can be attached to tickets by drag and drop)

@skiphansen commented on GitHub (Mar 20, 2025): Please provide a complete capture of the serial log from power up until after you attempt to change the channel. That should tell us what's happening or at least give us more clues. (just FYI: files can be attached to tickets by drag and drop)

sascha_hemi commented

@Rudios81 commented on GitHub (Mar 20, 2025):

I'll do that tomorrow

@Rudios81 commented on GitHub (Mar 20, 2025): I'll do that tomorrow

sascha_hemi commented

@Rudios81 commented on GitHub (Mar 21, 2025):

OEPL-C6-logs.txt
The attached file contains the C6 debug log.
It starts with normal communication to the tags.
Then I hit the reset button on the board and after a short time, tags came back to communicate.
At some point I changed the channel in the gui from 15 to 26 (while the logs did indicate is is using channel 25).
No channel related logs, only 3 lines of

I (35164) MAIN: SCP In
I (35384) MAIN: SCP In
I (35604) MAIN: SCP In

Very shortly after, tags came back in communicating, no change of channel seen on their cards.

@Rudios81 commented on GitHub (Mar 21, 2025): [OEPL-C6-logs.txt](https://github.com/user-attachments/files/19382217/OEPL-C6-logs.txt) The attached file contains the C6 debug log. It starts with normal communication to the tags. Then I hit the reset button on the board and after a short time, tags came back to communicate. At some point I changed the channel in the gui from 15 to 26 (while the logs did indicate is is using channel 25). No channel related logs, only 3 lines of ``` I (35164) MAIN: SCP In I (35384) MAIN: SCP In I (35604) MAIN: SCP In ``` Very shortly after, tags came back in communicating, no change of channel seen on their cards.

sascha_hemi commented

@nlimper commented on GitHub (Mar 21, 2025):

At least you found one small bug: channel 26 is not supposed to be a choice in the dropdown of the channel config, as the C6 is not capable of using channel 26 (only the segmented tag that was used as the ieee801.15.4 radio in the beginning of the OEPL project was capable of using that channel).
I will fix the web interface. But sadly it will probably not solve your problem.
Sorry, I was mistaken. Channel 27 has that properties. Using channel 26 is allright.

@nlimper commented on GitHub (Mar 21, 2025): ~~At least you found one small bug: channel 26 is not supposed to be a choice in the dropdown of the channel config, as the C6 is not capable of using channel 26 (only the segmented tag that was used as the ieee801.15.4 radio in the beginning of the OEPL project was capable of using that channel). I will fix the web interface. But sadly it will probably not solve your problem.~~ Sorry, I was mistaken. Channel 27 has that properties. Using channel 26 is allright.

sascha_hemi commented

@Rudios81 commented on GitHub (Mar 21, 2025):

Which is also funny, I have set the channel to auto on the config page, and now the AP status page shows channel 11, while still all cards of the tags show 25.
Just checked, channel 25 is also still the one indicated on the startup log of the C6 chip
My S3 chip has a TFT display, I have set it to show AP info, that also shows 25 by the way.

@Rudios81 commented on GitHub (Mar 21, 2025): Which is also funny, I have set the channel to auto on the config page, and now the AP status page shows channel 11, while still all cards of the tags show 25. Just checked, channel 25 is also still the one indicated on the startup log of the C6 chip My S3 chip has a TFT display, I have set it to show AP info, that also shows 25 by the way.

sascha_hemi commented

@nlimper commented on GitHub (Mar 21, 2025):

The only problem is that the C6 in your setup is not reacting correctly to channel change commands. All other findings are results of that.

@nlimper commented on GitHub (Mar 21, 2025): The only problem is that the C6 in your setup is not reacting correctly to channel change commands. All other findings are results of that.

sascha_hemi commented

@atc1441 commented on GitHub (Mar 21, 2025):

@Rudios81 maybe try out this old version of the C6 Firmware to check if it shows the same behavior(it has no SubGhz) then we know if its the C6 or S3 fault
ed82795e5f/ARM_Tag_FW/OpenEPaperLink_esp32_C6_AP/OpenEPaperLink_esp32_C6_AP_beta.bin

@atc1441 commented on GitHub (Mar 21, 2025): @Rudios81 maybe try out this old version of the C6 Firmware to check if it shows the same behavior(it has no SubGhz) then we know if its the C6 or S3 fault https://github.com/OpenEPaperLink/OpenEPaperLink/blob/ed82795e5f719f2eccc6296411bbc0a3449b2596/ARM_Tag_FW/OpenEPaperLink_esp32_C6_AP/OpenEPaperLink_esp32_C6_AP_beta.bin

sascha_hemi commented

@Rudios81 commented on GitHub (Mar 21, 2025):

@atc1441 Unfortunately that binary leaves my C6 in bootloop.
Attached is a short log of the debug

OEPL-C6-boot-loop.txt

@Rudios81 commented on GitHub (Mar 21, 2025): @atc1441 Unfortunately that binary leaves my C6 in bootloop. Attached is a short log of the debug [OEPL-C6-boot-loop.txt](https://github.com/user-attachments/files/19387283/OEPL-C6-boot-loop.txt)

sascha_hemi commented

@atc1441 commented on GitHub (Mar 21, 2025):

@Rudios81 did you flash the needed Bootloader and Partition files as well ?

@atc1441 commented on GitHub (Mar 21, 2025): @Rudios81 did you flash the needed Bootloader and Partition files as well ?

sascha_hemi commented

@Rudios81 commented on GitHub (Mar 21, 2025):

@atc1441 Probably not, but where can I find those?
I don't see them in the folder of the linked C6 binary.

@Rudios81 commented on GitHub (Mar 21, 2025): @atc1441 Probably not, but where can I find those? I don't see them in the folder of the linked C6 binary.

sascha_hemi commented

229962165a/binaries/ESP32-C6

@atc1441 commented on GitHub (Mar 21, 2025):

@atc1441 commented on GitHub (Mar 21, 2025): https://github.com/OpenEPaperLink/OpenEPaperLink/tree/229962165ae4faf8925cacbf3ec71a12a4f35975/binaries/ESP32-C6

sascha_hemi commented

@Rudios81 commented on GitHub (Mar 21, 2025):

Downloading the bootloader and partition too did not change anything

OEPL-C6-boot-loop2.txt

@Rudios81 commented on GitHub (Mar 21, 2025): Downloading the bootloader and partition too did not change anything [OEPL-C6-boot-loop2.txt](https://github.com/user-attachments/files/19387621/OEPL-C6-boot-loop2.txt)

sascha_hemi commented

@atc1441 commented on GitHub (Mar 21, 2025):

How do you flash it?

@atc1441 commented on GitHub (Mar 21, 2025): How do you flash it?

sascha_hemi commented

@Rudios81 commented on GitHub (Mar 21, 2025):

I removed the existing files from the storage of the S3 board via the ESP editor page.
From there I uploaded the files you pointed me to.
Then I hit the "Update ESP32-C6" button on the web gui, with the checkbox UNchecked.

One little detail. I compared both the bootloader and partition table from your linked folder against the ones I downloaded from my AP (I just wanted to keep them if I would need them later) but in both cases they are the same.

@Rudios81 commented on GitHub (Mar 21, 2025): I removed the existing files from the storage of the S3 board via the ESP editor page. From there I uploaded the files you pointed me to. Then I hit the "Update ESP32-C6" button on the web gui, with the checkbox UNchecked. One little detail. I compared both the bootloader and partition table from your linked folder against the ones I downloaded from my AP (I just wanted to keep them if I would need them later) but in both cases they are the same.

sascha_hemi commented

@atc1441 commented on GitHub (Mar 21, 2025):

Ok strange, did try it the same way just to recheck my own mind but it works fine. Maybe your C6 is a different chip version.
Then it will not be a simple test, forget about that please :)
Next step would be to compile your own C6 version without some SubGhz parts added to find the reason.

@atc1441 commented on GitHub (Mar 21, 2025): Ok strange, did try it the same way just to recheck my own mind but it works fine. Maybe your C6 is a different chip version. Then it will not be a simple test, forget about that please :) Next step would be to compile your own C6 version without some SubGhz parts added to find the reason.

sascha_hemi commented

@Rudios81 commented on GitHub (Mar 21, 2025):

That is then for some other time.
Only been working on conpiling the S3 image in the past.
Is there an easy procedure how to compile this C6 image?

@Rudios81 commented on GitHub (Mar 21, 2025): That is then for some other time. Only been working on conpiling the S3 image in the past. Is there an easy procedure how to compile this C6 image?

sascha_hemi commented

@atc1441 commented on GitHub (Mar 21, 2025):

Is there an easy procedure how to compile this C6 image?

Its as simply as installing the idf and enter compile :)

@atc1441 commented on GitHub (Mar 21, 2025): > Is there an easy procedure how to compile this C6 image? Its as simply as installing the idf and enter compile :)

sascha_hemi commented

https://github.com/OpenEPaperLink/OpenEPaperLink/wiki/Building-an-Access-Point#building-the-esp32-c6-radio-firmware-from-source

@skiphansen commented on GitHub (Mar 21, 2025):

If you run idf.py menuconfig you'll find a choice for OEPL config, choose that and you'll find an option for enabling/disabling the subGhz code.

(Top) â OEPL config
                                                             Espressif IoT Development Framework Configuration
    Hardware profile (Default)  --->
[*] Enable SubGhz Support
        CC1101 Configuration  --->

@skiphansen commented on GitHub (Mar 21, 2025): https://github.com/OpenEPaperLink/OpenEPaperLink/wiki/Building-an-Access-Point#building-the-esp32-c6-radio-firmware-from-source If you run idf.py menuconfig you'll find a choice for OEPL config, choose that and you'll find an option for enabling/disabling the subGhz code. ``` (Top) â OEPL config Espressif IoT Development Framework Configuration Hardware profile (Default) ---> [*] Enable SubGhz Support CC1101 Configuration ---> ```

sascha_hemi commented

@Rudios81 commented on GitHub (Mar 26, 2025):

I finally found the time to dive into compiling the C6 images myself.
I first installed the ESP-IDF package and managed to build the image using the latest github source code.
Uploaded the first build binary into my ESP-S3 and updated the C6 chip from the update page on the web-gui.
First conclusion, no change in behaviour, no logs about the channel on the debug output of the C6 chip when changing the channel on the web gui.
After the first build, I ran the menuconfig and disabled the subGhz component.
Again, uploaded the new (smaller) binary into the S3 -> update on the gui -> change channel ->
Hooray, I see logs about the channel and the channel indication also changes on my AP info shown on the display of the S3 chip.
I think i can thereby conclude that somewhere in the subGHz code, the channel alteration gets broken?

###DISCLAIMER###
I have to make a small disclaimer on this. The story above is was performed on my personal OpenEPaperLink github repo, that I did not sync towards the latest original master, I was last synced on March 21.
I just did a sync from the original repo back into my personal one and now building the binaries again, report asap.

###FINAL CONCLUSION###
Nothing has changed as compared to my experiences before.
The binary with SubGHz enabled won't allow to change the channel
The binary with SubGHz disabled, will be able to change the channel

@Rudios81 commented on GitHub (Mar 26, 2025): I finally found the time to dive into compiling the C6 images myself. I first installed the ESP-IDF package and managed to build the image using the latest github source code. Uploaded the first build binary into my ESP-S3 and updated the C6 chip from the update page on the web-gui. First conclusion, no change in behaviour, no logs about the channel on the debug output of the C6 chip when changing the channel on the web gui. After the first build, I ran the menuconfig and disabled the subGhz component. Again, uploaded the new (smaller) binary into the S3 -> update on the gui -> change channel -> Hooray, I see logs about the channel and the channel indication also changes on my AP info shown on the display of the S3 chip. I think i can thereby conclude that somewhere in the subGHz code, the channel alteration gets broken? ###DISCLAIMER### I have to make a small disclaimer on this. The story above is was performed on my personal OpenEPaperLink github repo, that I did not sync towards the latest original master, I was last synced on March 21. I just did a sync from the original repo back into my personal one and now building the binaries again, report asap. ###FINAL CONCLUSION### Nothing has changed as compared to my experiences before. The binary with SubGHz enabled won't allow to change the channel The binary with SubGHz disabled, will be able to change the channel

sascha_hemi commented

@skiphansen commented on GitHub (Mar 26, 2025):

Thanks for isolating this!

I'll look into it and if I can reproduce it I should be able to fix it.

Skip

@skiphansen commented on GitHub (Mar 26, 2025): Thanks for isolating this! I'll look into it and if I can reproduce it I should be able to fix it. Skip

sascha_hemi commented

@Rudios81 commented on GitHub (Mar 27, 2025):

Glad to be of any help, hope you'll be able to pinpoint the issue.
Just another question. Will the C6 (and also H2 for that matter) be included into the global releases in the future or will this always be a dedicated piece of code/binary?
The reason I'm asking is because I noticed that I never succeed in updating the C6 image when the checkbox "download latest version" is checked. I assume that the location of the C6 binary is hard-coded somewhere, but can't it be integreated into the release side by side with the various S3 binaries?

@Rudios81 commented on GitHub (Mar 27, 2025): Glad to be of any help, hope you'll be able to pinpoint the issue. Just another question. Will the C6 (and also H2 for that matter) be included into the global releases in the future or will this always be a dedicated piece of code/binary? The reason I'm asking is because I noticed that I never succeed in updating the C6 image when the checkbox "download latest version" is checked. I assume that the location of the C6 binary is hard-coded somewhere, but can't it be integreated into the release side by side with the various S3 binaries?

sascha_hemi commented

@nlimper commented on GitHub (Mar 27, 2025):

Currently (version 2.75) the C6/H2 firmware is downloaded from a fixed location (which is maintained by me, and currently contains a 'known good' version, not the latest), or, when you uncheck the checkbox, it will use the location on your flash file system, so you can manually place the files there.
@skiphansen did some work to make it more flexible, so the C6/H2 firmware can be made part of a release. Those changes will be visible on the next release.

@nlimper commented on GitHub (Mar 27, 2025): Currently (version 2.75) the C6/H2 firmware is downloaded from a fixed location (which is maintained by me, and currently contains a 'known good' version, not the latest), or, when you uncheck the checkbox, it will use the location on your flash file system, so you can manually place the files there. @skiphansen did some work to make it more flexible, so the C6/H2 firmware can be made part of a release. Those changes will be visible on the next release.

sascha_hemi commented

@Rudios81 commented on GitHub (Mar 27, 2025):

Thanks @nlimper for the answer, sounds promising!
What is the location of your hosted C6 images? I have never been able to successfully download the binary when updating with the checkbox turned on.
Additionally, will the update with checkbox checked also download the bootloader.bin and partition-table.bin files?

@Rudios81 commented on GitHub (Mar 27, 2025): Thanks @nlimper for the answer, sounds promising! What is the location of your hosted C6 images? I have never been able to successfully download the binary when updating with the checkbox turned on. Additionally, will the update with checkbox checked also download the bootloader.bin and partition-table.bin files?

sascha_hemi commented

@nlimper commented on GitHub (Mar 27, 2025):

currently:
https://github.com/OpenEPaperLink/OpenEPaperLink/blob/master/binaries/ESP32-C6/firmware.json
and for every file mentioned in that json, it fetches the file from http://www.openepaperlink.eu/binaries/ESP32-C6/
but with the next release, they will be downloaded from the release files.

@nlimper commented on GitHub (Mar 27, 2025): currently: https://github.com/OpenEPaperLink/OpenEPaperLink/blob/master/binaries/ESP32-C6/firmware.json and for every file mentioned in that json, it fetches the file from http://www.openepaperlink.eu/binaries/ESP32-C6/ but with the next release, they will be downloaded from the release files.

sascha_hemi commented

@Rudios81 commented on GitHub (Mar 27, 2025):

Ok, thanks. Very weird. I can easily (and as expected) download all 3 files mentioned in the JSON file from the location you pointed out. That makes me curious why my AP won't be able to do this as well

@Rudios81 commented on GitHub (Mar 27, 2025): Ok, thanks. Very weird. I can easily (and as expected) download all 3 files mentioned in the JSON file from the location you pointed out. That makes me curious why my AP won't be able to do this as well

sascha_hemi commented

@skiphansen commented on GitHub (Mar 27, 2025):

There were some timing issues in the DL code. There's a Beta of the new OTA changes you can test if you like.
See https://github.com/skiphansen/OpenEPaperLink/wiki/Installing-the-Coprocessor-OTA-Beta for details.

@skiphansen commented on GitHub (Mar 27, 2025): There were some timing issues in the DL code. There's a Beta of the new OTA changes you can test if you like. See https://github.com/skiphansen/OpenEPaperLink/wiki/Installing-the-Coprocessor-OTA-Beta for details.

sascha_hemi commented

@skiphansen commented on GitHub (Mar 27, 2025):

Never mind ... I forgot that you were running a custom build so the Beta isn't going to work for you.
You could rebuild your custom image and reflash from scratch since the Beta has been merged into the main repo.
Don't forget to clear your browser cache if you give it a go, there were lots of Javascript changes.

@skiphansen commented on GitHub (Mar 27, 2025): Never mind ... I forgot that you were running a custom build so the Beta isn't going to work for you. You could rebuild your custom image and reflash from scratch since the Beta has been merged into the main repo. Don't forget to clear your browser cache if you give it a go, there were lots of Javascript changes.

sascha_hemi commented

@Rudios81 commented on GitHub (Mar 27, 2025):

@skiphansen I'll definitely will give it a try. I have very limited alterations in my own repo, actually I am in sync up till yesterday.
I'll create a release tomorrow and update from there.
I'll report asap.

@Rudios81 commented on GitHub (Mar 27, 2025): @skiphansen I'll definitely will give it a try. I have very limited alterations in my own repo, actually I am in sync up till yesterday. I'll create a release tomorrow and update from there. I'll report asap.

sascha_hemi commented

@skiphansen commented on GitHub (Mar 28, 2025):

Nic just did a new release which includes the OTA changes so it would be better if you just synced up with the master repo and tried the new release.

I may have reproduced your issue using an Elcrow C6 module on an Elcrow Advanced 2.8 HMI screen.

When I try to set the channel with subGhz enabled I get this in the log:

ingACK> ok, 18ms
I (735304) MAIN: RDY? In
I (740914) MAIN: SCP In
SCP send failed in try 0
NOK>SCP send failed in try 1
I (741244) MAIN: SCP In
SCP send failed in try 2
NOK>SCP send failed in try 3
I (741464) MAIN: SCP In
SCP send failed in try 4
SCP failed to send...

The code looks right so I'll have to debug it.

Theory: The pin assignments for the C6 subGhz interface are conflicting with something on the ELECROW C6 module and possibly the C6 module you are using.

Not sure why that would cause the issue I'm seeing yet.

Channel change works find w/o the subGhz code.

@skiphansen commented on GitHub (Mar 28, 2025): Nic just did a new release which includes the OTA changes so it would be better if you just synced up with the master repo and tried the new release. I may have reproduced your issue using an Elcrow C6 module on an Elcrow Advanced 2.8 HMI screen. When I try to set the channel with subGhz enabled I get this in the log: ``` ingACK> ok, 18ms I (735304) MAIN: RDY? In I (740914) MAIN: SCP In SCP send failed in try 0 NOK>SCP send failed in try 1 I (741244) MAIN: SCP In SCP send failed in try 2 NOK>SCP send failed in try 3 I (741464) MAIN: SCP In SCP send failed in try 4 SCP failed to send... ``` The code looks right so I'll have to debug it. Theory: The pin assignments for the C6 subGhz interface are conflicting with something on the ELECROW C6 module and possibly the C6 module you are using. Not sure why that would cause the issue I'm seeing yet. Channel change works find w/o the subGhz code.

sascha_hemi commented

@Rudios81 commented on GitHub (Mar 28, 2025):

Great work again, after syncing my own repo to the master repo and created a new release 2.81 on my personal repo.
All went fine and updating was just as smooth as before, so running the 2.81 AP version now.
Also managed to update my C6 chip using the "Latest version from repo" selected update method.
Just have to confirm the channel change behaviour.
I assume the C6 chip firmware on the release is build with subGHz enabled, so I assume I can't change the channel anymore but I'll need to check the debug logs to confirm.

@Rudios81 commented on GitHub (Mar 28, 2025): Great work again, after syncing my own repo to the master repo and created a new release 2.81 on my personal repo. All went fine and updating was just as smooth as before, so running the 2.81 AP version now. Also managed to update my C6 chip using the "Latest version from repo" selected update method. Just have to confirm the channel change behaviour. I assume the C6 chip firmware on the release is build with subGHz enabled, so I assume I can't change the channel anymore but I'll need to check the debug logs to confirm.

sascha_hemi commented

@nlimper commented on GitHub (Mar 28, 2025):

The flow is as following:

the S3 sends an SCP command to the C6
the C6 waits until all bytes of the espSetChannelPower struct are received. It looks up the channel, and sends an >ACK (acknowledge) or >NOK (not acknowledged because the channel cannot be found in the list of const uint8_t channelList[6] = {11, 15, 20, 25, 26, 27};).
this code: https://github.com/OpenEPaperLink/OpenEPaperLink/blob/master/ARM_Tag_FW/OpenEPaperLink_esp32_C6_AP/main/main.c#L352-L383
According to the serial logs, a NOK is send, indicating the SCPfailed branch is triggered, because apparently the channel cannot be found in the channel list. Only thing is, I don't see why that would happen, as the SubGHz additions don't look like they interfere with that. But the issue should be somewhere in that region...

@nlimper commented on GitHub (Mar 28, 2025): The flow is as following: - the S3 sends an SCP command to the C6 - the C6 waits until all bytes of the `espSetChannelPower` struct are received. It looks up the channel, and sends an >ACK (acknowledge) or >NOK (not acknowledged because the channel cannot be found in the list of `const uint8_t channelList[6] = {11, 15, 20, 25, 26, 27};`). this code: https://github.com/OpenEPaperLink/OpenEPaperLink/blob/master/ARM_Tag_FW/OpenEPaperLink_esp32_C6_AP/main/main.c#L352-L383 According to the serial logs, a NOK is send, indicating the SCPfailed branch is triggered, because apparently the channel cannot be found in the channel list. Only thing is, I don't see why that would happen, as the SubGHz additions don't look like they interfere with that. But the issue should be somewhere in that region...

sascha_hemi commented

@skiphansen commented on GitHub (Mar 28, 2025):

I figured it out. Here's the problem (from proto.h)

struct espSetChannelPower {
    uint8_t checksum;
    uint8_t channel;
    uint8_t power;
#ifdef CONFIG_OEPL_SUBGIG_SUPPORT
    uint8_t subghzchannel;
#endif
} __attribute__((packed, aligned(1)));

So the length of the channel change message depends on HAS_SUBGHZ in platformio.ini.
If the S3 code is configured w/o HAS_SUBGHZ then the corresponding C6 binary must also be
compiled w/o subGhz enabled. If this is not the case the CRC check on the message
will fail because of the disagreement on message length.

So ... adding -D HAS_SUBGHZ to your configuration and rebuilding the S3 code
should fix your problem with the stock C6 binary.

@skiphansen commented on GitHub (Mar 28, 2025): I figured it out. Here's the problem (from proto.h) ```c struct espSetChannelPower { uint8_t checksum; uint8_t channel; uint8_t power; #ifdef CONFIG_OEPL_SUBGIG_SUPPORT uint8_t subghzchannel; #endif } __attribute__((packed, aligned(1))); ``` So the length of the channel change message depends on HAS_SUBGHZ in platformio.ini. If the S3 code is configured w/o HAS_SUBGHZ then the corresponding C6 binary must also be compiled w/o subGhz enabled. If this is not the case the CRC check on the message will fail because of the disagreement on message length. So ... adding -D HAS_SUBGHZ to your configuration and rebuilding the S3 code should fix your problem with the stock C6 binary.

sascha_hemi commented

@skiphansen commented on GitHub (Mar 28, 2025):

BTW it is fine to use the stock C6 w/o a subGhz module connected. The firmware probes for the module at startup and only uses it when it's detected.

@skiphansen commented on GitHub (Mar 28, 2025): BTW it is fine to use the stock C6 w/o a subGhz module connected. The firmware probes for the module at startup and only uses it when it's detected.

sascha_hemi commented