What is expected behavior with Custom_PriceTag_AccessPoint?

[szczys]

I've flashed the board with Platformio but cannot figure out how to use this. Loading the IP addess (port 80) results in a blank page, although I do see the request in the monitor. The startup sequence throws this error in the monitor: E (3616) SPIFFS: mount failed, -10025

Here's what it looks like when trying to load page:

_HEADER[Host]: 192.168.1.195
_HEADER[User-Agent]: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:85.0) Gecko/20100101 Firefox/85.0
_HEADER[Accept]: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
_HEADER[Accept-Language]: en-US,en;q=0.5
_HEADER[Accept-Encoding]: gzip, deflate
_HEADER[Connection]: keep-alive
_HEADER[Upgrade-Insecure-Requests]: 1
_HEADER[Cache-Control]: max-age=0

Monitor then streams output like this indefinitely:

Sync: 0x1 0xFE 0xE 0x0 0x0 0x0 0x0
250854 Normal: short SYNC done
250855 Main: Mode changed to Idle
250855 Main: Idle
251937 Main: Count: 4
251937 Main: Mode changed to Sync
251937 Main: Sync
Sync: 0x1 0xFE 0xF 0x0 0x0 0x0 0x0
251954 Normal: short SYNC done
251955 Main: Mode changed to Idle
251955 Main: Idle
253037 Main: Count: 4
253037 Main: Mode changed to Sync
253037 Main: Sync
Sync: 0x1 0xFE 0x0 0x0 0x0 0x0 0x0
253054 Normal: short SYNC done
253055 Main: Mode changed to Idle
253055 Main: Idle
254137 Main: Count: 4
254137 Main: Mode changed to Sync
254137 Main: Sync```

[interzen]

Here are the directions I got from Aaron: You need to supply your wifi credentials in the wlan.h after renaming the existing one(wlan_gitignore_replacement.h). After that you need to open the ip/edit site, admin admin, and upload the index.htm to the esp then you can open ip

[atc1441]

Hey.

Yes so far as @interzen wrote, you already have if connect to wifi thats good and only the index.htm needs to be uploaded now via /edit, the mount error is on first boot , the spiffs is formated after that.

After that a display can be activated as shown here https://youtu.be/p4wd8amFLck The image needs to be a monochrome .bmp and if two colors are wanted two monochrome files need to be supplied in the edit fields.

One additional thing, have patients, only every 16 seconds a display will be contacted.

Also once a display is activated it is configured to the netID, Freq and Slot count. So if some of this is changed the displays need to be re activated.

Yes its not very userfriendly right now but the function was more important :D

[szczys]

Thanks both for the help. This gets me closer, but I'm having trouble waking my display. I checked one of the coin cells with a DMM (no load) and get 3.0 V. Continuing to scratch my head ;-)

831560 Main: Mode changed to Wakeup Activation
831561 Main: Wakeup Activation
Wu Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x1 0x0 0x1
831562 Verbose: Radio set to base freq: (F=4) 869.85 Mhz 
831562 Verbose: Radio set id done 0
831654 Main: Count: 23
832754 Main: Count: 250
833854 Main: Count: 247
834954 Main: Count: 249
836054 Main: Count: 249
837154 Main: Count: 248
838254 Main: Count: 248
839354 Main: Count: 249
840454 Main: Count: 249
841554 Main: Count: 248
842654 Main: Count: 249
843754 Main: Count: 248
844854 Main: Count: 249
845954 Main: Count: 248
847054 Main: Count: 249
847063 Main: WAKEUP Activation done
847063 Main: Mode changed to Activation
847063 Main: Activation
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x80 0x3 0x1 0x0 0x8E 0x0 0x0 0x0 0x0
847109 Main: RX Timeout retry
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x80 0x3 0x1 0x0 0x8E 0x0 0x0 0x0 0x0
847155 Main: RX Timeout retry
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x80 0x3 0x1 0x0 0x8E 0x0 0x0 0x0 0x0
847201 Main: RX Timeout retry
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x80 0x3 0x1 0x0 0x8E 0x0 0x0 0x0 0x0
847247 Main: RX Timeout retry
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x80 0x3 0x1 0x0 0x8E 0x0 0x0 0x0 0x0
847293 Main: RX Timeout retry
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x80 0x3 0x1 0x0 0x8E 0x0 0x0 0x0 0x0
847339 Main: RX Timeout retry
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x80 0x3 0x1 0x0 0x8E 0x0 0x0 0x0 0x0
847385 Main: RX Timeout retry
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x80 0x3 0x1 0x0 0x8E 0x0 0x0 0x0 0x0
847431 Main: RX Timeout retry
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x80 0x3 0x1 0x0 0x8E 0x0 0x0 0x0 0x0
847477 Main: RX Timeout retry
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x80 0x3 0x1 0x0 0x8E 0x0 0x0 0x0 0x0
847523 Main: RX Timeout retry
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x80 0x3 0x1 0x0 0x8E 0x0 0x0 0x0 0x0
847569 Main: no connection possible, exit activation

[atc1441]

You can just try it a few times, What also may helps is to set a different Frequenzy like 2 just dont use 4

If the display sees the sync messages on the freq it is already configured it will not look for the activation messages. Hard to explain

CC1101 is definitely connected right

[szczys]

Thanks for the help. Still not working but a bit more progress. I took batteries out and powered from bench supply at 3.0 V. I played with frequency settings and was able to see the current jump to 8-5 mA, then stabilize at 21 mA. This makes me think it was waking up to be activated.

Much trail on this but it's hard to replicate. I did get this at one point but haven't been able to get it again:

133956 Main: Mode changed to Wakeup Activation
133956 Main: Wakeup Activation
Wu Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x2 0x0 0x1
133957 Verbose: Radio set to base freq: (F=4) 869.85 Mhz 
133957 Verbose: Radio set id done 0
134255 Main: Count: 70
135355 Main: Count: 248
136455 Main: Count: 248
137555 Main: Count: 249
138655 Main: Count: 248
139755 Main: Count: 248
140855 Main: Count: 248
141955 Main: Count: 250
143055 Main: Count: 248
144155 Main: Count: 249
145255 Main: Count: 248
146355 Main: Count: 249
147455 Main: Count: 248
148555 Main: Count: 248
149460 Main: WAKEUP Activation done
149460 Main: Mode changed to Activation
149460 Main: Activation
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x80 0x3 0x1 0x0 0x7A 0x0 0x0 0x0 0x0
149507 Main: RX Timeout retry
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x80 0x3 0x1 0x0 0x7A 0x0 0x0 0x0 0x0
149519 Normal: RSSI: 255 LQI: 127
 Read_len:12 Data: 0xA 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x80 0x2 0x2B 0x35
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x81 0x4 0x0 0x2 0x0 0x0 0x0 0x0 0x0
149532 Normal: RSSI: 255 LQI: 127
 Read_len:12 Data: 0xA 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x81 0x2 0x2B 0x36
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x82 0x4 0x1 0x0 0x0 0x0 0x0 0x0 0x0
149579 Main: RX Timeout retry
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x82 0x4 0x1 0x0 0x0 0x0 0x0 0x0 0x0
149625 Main: RX Timeout retry
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x82 0x4 0x1 0x0 0x0 0x0 0x0 0x0 0x0
149655 Main: Count: 213
149671 Main: RX Timeout retry
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x82 0x4 0x1 0x0 0x0 0x0 0x0 0x0 0x0
Error while reading RX buffer
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x83 0x4 0x2 0x0 0x0 0x0 0x0 0x0 0x0
149694 Normal: RSSI: 255 LQI: 127
 Read_len:12 Data: 0xA 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x83 0x2 0x2B 0x35
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x84 0x4 0x3 0x0 0x0 0x0 0x0 0x0 0x0
149707 Normal: RSSI: 255 LQI: 127
 Read_len:12 Data: 0xA 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x84 0x2 0x2B 0x35
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x85 0x4 0x4 0x0 0x0 0x0 0x0 0x0 0x0
149720 Normal: RSSI: 255 LQI: 127
 Read_len:12 Data: 0xA 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x85 0x2 0x2B 0x36
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x86 0x4 0x5 0x0 0x0 0x0 0x0 0x0 0x0
149734 Normal: RSSI: 255 LQI: 127
 Read_len:12 Data: 0xA 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x86 0x2 0x2B 0x36
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x87 0x4 0x6 0x0 0x0 0x0 0x0 0x0 0x0
149747 Normal: RSSI: 255 LQI: 127
 Read_len:12 Data: 0xA 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x87 0x2 0x2B 0x36
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x88 0x4 0x7 0x0 0x0 0x0 0x0 0x0 0x0
149760 Normal: RSSI: 255 LQI: 127
 Read_len:12 Data: 0xA 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x88 0x2 0x2B 0x35
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x89 0x5 0x10 0x0 0x0 0x0 0x0 0x0 0x0
149773 Normal: RSSI: 255 LQI: 127
 Read_len:12 Data: 0xA 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x89 0x2 0x2B 0x36
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x8A 0x6 0x4 0x4C 0x0 0x0 0x0 0x0 0x0
Error while reading RX buffer
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x8B 0x7 0x5 0x0 0x0 0x0 0x0 0x0 0x0
149832 Main: RX Timeout retry
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x8B 0x7 0x5 0x0 0x0 0x0 0x0 0x0 0x0
149878 Main: RX Timeout retry
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x8B 0x7 0x5 0x0 0x0 0x0 0x0 0x0 0x0
149924 Main: RX Timeout retry
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x8B 0x7 0x5 0x0 0x0 0x0 0x0 0x0 0x0
149970 Main: RX Timeout retry
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x8B 0x7 0x5 0x0 0x0 0x0 0x0 0x0 0x0
Error while reading RX buffer
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x8C 0x8 0x39 0x0 0x0 0x0 0x0 0x0 0x0
149993 Normal: RSSI: 255 LQI: 127
 Read_len:12 Data: 0xA 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x8C 0x2 0x2B 0x36
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x8D 0x9 0x40 0x0 0x0 0x0 0x0 0x0 0x0
Error while reading RX buffer
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x8E 0xA 0xFF 0xF0 0x0 0x0 0x0 0x0 0x0
150019 Normal: RSSI: 255 LQI: 127
 Read_len:12 Data: 0xA 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x8E 0x2 0x2B 0x35
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x81 0xB 0x0 0x3 0x0 0x0 0x0 0x0 0x0
Error while reading RX buffer
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x82 0xC 0x0 0x1 0x0 0x0 0x0 0x0 0x0
150078 Main: RX Timeout retry
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x82 0xC 0x0 0x1 0x0 0x0 0x0 0x0 0x0
150124 Main: RX Timeout retry
Activation: 0x0 0x4A 0x4D 0x10 0x17 0x73 0x15 0x82 0xC 0x0 0x1 0x0 0x0 0x0 0x0 0x0
150170 Main: no connection possible, exit activation

[atc1441]

This does indee look good.

But not perfect the rssi is very high as it seems.

What module do you have ? Could it be that its an 433mhz version? You need a 868mhz version

[szczys]

It's an AliExpress special and should be 868. I ordered 2 and should try the other but perhaps I need a module of better provenance.

[jruys]

I'm having similar issues - I can hear (on my Kenwood receiver) the wakeup carrier happening. When it switches to activation, the RX timeouts happen near instantly and it gives up. Is that expected? My uninformed guess is that RX isn't working properly for me.

Tried various channels and two different CP1101's and ESP32 (Wemos D1 ESP32 Ali clone).

11:58:14.471 -> 709744 Main: Count: 248 11:58:15.566 -> 710844 Main: Count: 249 11:58:15.704 -> 710948 Main: WAKEUP Activation done 11:58:15.704 -> 710948 Main: Mode changed to Activation 11:58:15.704 -> 710948 Main: Activation 11:58:15.704 -> Activation: 0x0 0x6A 0x61 0x10 0x75 0x15 0x69 0x80 0x3 0x1 0x0 0x7F 0x0 0x0 0x0 0x0 11:58:15.749 -> 710994 Main: RX Timeout retry 11:58:15.749 -> Activation: 0x0 0x6A 0x61 0x10 0x75 0x15 0x69 0x80 0x3 0x1 0x0 0x7F 0x0 0x0 0x0 0x0 11:58:15.795 -> 711040 Main: RX Timeout retry 11:58:15.795 -> Activation: 0x0 0x6A 0x61 0x10 0x75 0x15 0x69 0x80 0x3 0x1 0x0 0x7F 0x0 0x0 0x0 0x0 11:58:15.841 -> 711086 Main: RX Timeout retry 11:58:15.841 -> Activation: 0x0 0x6A 0x61 0x10 0x75 0x15 0x69 0x80 0x3 0x1 0x0 0x7F 0x0 0x0 0x0 0x0 11:58:15.886 -> 711132 Main: RX Timeout retry 11:58:15.886 -> Activation: 0x0 0x6A 0x61 0x10 0x75 0x15 0x69 0x80 0x3 0x1 0x0 0x7F 0x0 0x0 0x0 0x0 11:58:15.931 -> 711178 Main: RX Timeout retry

[jruys]

For reference - these are my CC1101 modules, both 868 according to Ali:

[atc1441]

@jruys the blue one is most likely 433mhz but the green one is the one i am using as well. But on some of the green ones is a bad osci. If possible replace it, i used one from an EPOP50 display as its proven to be the right osci.

Here as comparisson 433 to 868 schematics from the CC1101 datasheet

I made very good experience with the ebyte cc1101 modules. Its a bit more expensive but uses good components https://www.ebay.de/itm/124323749649

As activation info, once a display is activated to one channel/freq and there are sync messages on it it will not be listening on the wakeup channel/freq, to get arround this set a different channel for activation but not channel 4 as it is the activation channel. After that wait a few minutes then to activate again

[atc1441]

Just to have it linked here in this stream is a lot of the system explained and and activation and image upload done https://youtu.be/pRoFim3Egss

[jruys]

I watched the stream, but the screenshare where you guys do the activation (that succeeds on the 2nd try) is too fuzzy for me to see timestamps :-)

Q: After ESP switches from wakeup to activation, it only takes 1 second to go from "Mode changed to Activation" to "no connection possible, exit activation" (with 10 "RX Timeout retry"). Is that time expected to be only 1 second?

I've got one of those ebytes on order, let's hope it's not stuck in the Suez Canal.

[atc1441]

A: Yes, the Wakeup signal is send out 15,5 Seconds with the serial number of the wanted display and the Activation command.

Every "sleeping" display wakes up every 16 seconds and listens for a wakeup cmd. If it receives the Activation cmd it will wait till the end of the 15,5 Seconds ( depending on when it woke up ) and then listens again for the Activation cmds itself and directly answers if it receives some. The AP retrys 10 times to send the first cmd and if no answer is received it cancels the activation. This is happening in about 500ms at max as a timeout of 40ms is used

This means we do not know where it fails. Doesnt have to be wrong RX on AP. Could also be that the display simply doesnt wake up.

This is also the reason why this stock protocol is so hard to handle.

But today Dymitry did released its custom firmware for the Chroma74 if someone is into that. For now it runs on an nRF52840 Dongle with CC1101 where the nRF acts as an USB flash drive and a converted image can be placed on it to update the correct display https://twitter.com/dmitrygr/status/1374894828085932033?s=19 You can see some of the state of the display by hooking up an Amperemeter to its power supply. I made the experience that on low battery the display sometimes work and sometimes not

[atc1441]

@szczys and @jruys

@xsrf (Andreas) did just shared with me that he also uses the green one and both modules he received where 25khz off of the base freq, after he fixed the offset the display did worked as expected.

so its more and more likely its because of the "bad" oscillator on the green boards

[xsrf]

Hey, the frequency offset can be set via FSCTRL0 register here: https://github.com/atc1441/E-Paper_Pricetags/blob/809a00e232e2ba59982c48968888a1738a63871e/Custom_PriceTag_AccesPoint/ESP32_Async_PlatformIO/RFV3/cc1101.cpp#L62

The offset is ~1.6kHz per unit... I tried 0x0F and 0x11 and it worked with both.

  spi_write_register(CC1101_REG_CHANNR, 0x00);
  spi_write_register(CC1101_REG_FSCTRL1, 0x06);
  spi_write_register(CC1101_REG_FSCTRL0, 0x11); // Offset in ~1.6kHz steps
  spi_write_register(CC1101_REG_MDMCFG4, 0xCA);
  spi_write_register(CC1101_REG_MDMCFG3, 0x83);

I had an SDR handy to check if the 869.85 MHz of the wakeup channel actually were accurate though.

[jruys]

BINGO!

20:20:53.394 -> Activation: 0x0 0x4A 0x4D 0x10 0x2 0x96 0x35 0x80 0x3 0x1 0x0 0x7B 0x0 0x0 0x0 0x0 20:20:53.394 -> 36984 Normal: RSSI: 174 LQI: 46 20:20:53.394 -> Read_len:12 Data: 0xA 0x0 0x4A 0x4D 0x10 0x2 0x96 0x35 0x80 0x2 0x2B 0x51 20:20:53.394 -> Activation: 0x0 0x4A 0x4D 0x10 0x2 0x96 0x35 0x81 0x4 0x0 0x3 0x0 0x0 0x0 0x0 0x0 20:20:53.394 -> 36997 Normal: RSSI: 174 LQI: 46

Using 0x0F offset...

[atc1441]

wow great to hear another successful fix :)

[szczys]

Great work @xsrf -- I was able to get this working with 0x0F

[interzen]

Good to know the bad XTAL can be corrected for that easily. That will probably help my green 1101 modules work reliably like the more expensive red one I have. Thanks @xsrf

[atc1441]

Ok! now it gets interesting,

i also did set and offset of 0x0f just for fun for testing the Chroma29 as they where still making problems. and guess what. first try activation and sending an image :-O

Many thanks again to @xsrf

[xsrf]

Well, I can activate the chroma29 but I can't get commands to work so far. When I activated the chroma79 with ID 123 on NetID 1 the answers.txt recorded:

NetID: 1 freq: 0 display: 123 65299 = 85:05:96:0C:F3:00:01:00:00:00

and all is working fine.

When I activated the chroma29 with ID 124 on NetID 1 the answers.txt recorded:

NetID: 254 freq: 0 display: 39255 289940 = 12:9F:09:2F:00:00:03:00:00:04:00:00:9A:11:80:00:28:01:01:01:06:00:00:02:08:00:01:02:21:01:00:00:00:00:00

And so far it doesn't respond to any commands... I tried setting the NetID to 254 instead of 1. When id the NetID actually set? Also during activation? The "Activate" button only submits the serial and id though... Any idea what might be wrong?

[atc1441]

@xsrf the save answer from the Chroma29 is from the activation, in the new activation method a real communication is already made and that is what you see there, https://github.com/atc1441/E-Paper_Pricetags/blob/main/Custom_PriceTag_AccesPoint/ESP32_Async_PlatformIO/RFV3/mode_wun_activation.h#L147 the answer is encoded and return 12 for successful setting RF config, 9F for the Firmware data info's and later the 0x9A for the display info's like screen resolution.

it sounds to me that after activation the Chroma29 is not Synced and thats why it doesn't answer. after the RF communication for activation it does still take about 2 minutes till it is complete so please be patient there. and wait till the NetId and Freq changed in the status message back to the original set one, the new activation method used by the Chroma creates a new NetId and channel where all unactivated displays will be woken up to, its kind of like a temp full running mode

The netID, channel and Slots is set on activation to the current set netID and to the current Freq/Channel/Slot so changing it afterwords need to reactivate all displays again.

for me the Chroma29 did worked the best with 16 slots. i dont know if this is needed or something else is wrong

Hard to explain ^^

[atc1441]

Added a general info about all the CMD's and a bit parsing infos as well here: https://github.com/atc1441/E-Paper_Pricetags/blob/main/Custom_PriceTag_AccesPoint/CMDs%20explanation.txt

[xsrf]

okay, got it... successfully activated two chroma29:

NetID: 254 freq: 0 display: 2176 282297 = 12:9F:09:2F:00:00:03:00:00:04:00:00:9A:11:80:00:28:01:01:01:06:00:00:02:08:00:01:02:21:01:00:00:00:00:00
NetID: 1 freq: 0 display: 125 894699 = 85:05:94:0B:FA:00:01:00:00:00
NetID: 254 freq: 0 display: 39255 1328340 = 12:9F:09:2F:00:00:03:00:00:04:00:00:9A:11:80:00:28:01:01:01:06:00:00:02:08:00:01:02:21:01:00:00:00:00:00
NetID: 1 freq: 0 display: 124 2160799 = 85:05:99:0B:F6:00:01:00:00:00

took me about 10min after activation to get the first successful command through

[atc1441]

Seems like there is still something wrong with them as i also have not 100% success with them, all other displays work fine for me, so Chroma42 Chroma74 Epop50 Epop500 and Epop900 It must habe something todo with the new activation method. There are still some values in it i dont knwo what they are for Example: https://github.com/atc1441/E-Paper_Pricetags/blob/main/Custom_PriceTag_AccesPoint/ESP32_Async_PlatformIO/RFV3/mode_wun_activation.h#L134

I did added a function to set the Freq Offset on the fly to the web interface now to be able to test the correct one, -127 to 127 as value. Its not saves anywhere but the persistence storage is already started in the settings.h but not finished :)

[szczys]

Just a guess here, but can RSSI measurements be used to judge the effectiveness of the offset value?

[atc1441]

@szczys both the rssi and lqi should be able to be used for that yes https://wisense.wordpress.com/2014/12/23/understanding-rssi-and-lqi-values-reported-by-the-cc1101/

The rssi would be better to be displayed in an int8_t and not an uint8_t as it is now

[jruys]

Update: Chroma74 (ID 123) works fine. I have two Chroma29 that activated and two that don't respond at all (fresh batteries), tried different channels - no joy. Progress!

NetID: 1 freq: 2 display: 126 4750165 = 85:05:81:0B:E9:00:01:00:00:00 NetID: 1 freq: 2 display: 126 4785498 = 03:04:85:05:74:0B:EB:00:01:00 NetID: 1 freq: 2 display: 123 6946819 = 03:04:85:05:37:0C:06:01:01:00 NetID: 1 freq: 2 display: 127 15293664 = 85:05:8E:0B:D0:00:01:00:00:00 NetID: 1 freq: 2 display: 127 15540197 = 03:04:85:05:99:0B:CD:00:01:00

[atc1441]

Dont know where to post it else to not spam,

added persistence settings to the system just now,

so its not needed to re set Freq, NetID offset and lot count on every boot.

the index.htm needs to be updated as well

[szczys]

I've tested this and the new settings work well, nice addition!

I have noticed that my RF module drifts. I can always activate a display with the offset of 0x0f, 0x10, and 0x11. However, when trying to send bmp to the displays, I need to select from one of those and after a while may need to change which one. The failure mode I see is an RX Timeout! message.

I am using the green CC1101 868 Mhz boards which, as mentioned previously, have known oscillator tolerance issues. I have the red boards on order and can test this behavior with those when they arrive in... you know, May or so ;-)

[xsrf]

@szczys that's interesting. If I understand that correctly it means that the ESL successfully receives the commands but the module cannot read the response. If the ESL wouldn't receive the sync+commands (3 in a rows), it would switch back to the wake-up channel and thus wouldn't be able to receive the commands with a slightly changes frequency. @atc1441 please correct me if I'm wrong here...

[atc1441]

my guess would be that a different offset is needed for different frequencies,

The Activation is happening on channel 4 and the cmd transmission on the set one.

@szczys you could try to activate on channel 4 to be on the same channel all the time and see if things get better.

[xsrf]

@szczys when you said you can upload an image if you change the offet, I assume you didn't reactivate the display? or did you? would be interesting to know. I also noticed timeout issues with the croma29. however by monitoring the current of the display I confirmed that they were still in sync (wakeup period of 17.6s)

[atc1441]

@xsrf On what slot count did you activate the 29?

If 16 slots then it sounds right, i also encountered the most problems with them, all other ones work like they should. There is a cmd to set the rf group and rx/tx power on the displays that can help It is:

A2020100A402C2C2 Can be send at once

Change RF group: A2020100 Set RF Power A402C2C2

[xsrf]

So far I use 16 slots. I tried to reactivate with 2 or 4 slots but that failed so far. I may try again.

Can you give more details about these commands? What is an "RF group" supposed to do? Is there a way to query the current settings from the device? Like GetRfStats

You've listed these commands here, but without information on the parameters.

[atc1441]

Unfortunately not many parameters are known till now, they are very burried in the stock software so only the already used one are easy to encode.

RfStats contain these for example, but unknown of the order till now: public sbyte? rssi; public byte? lqi; public ushort? packetErrors; public ushort? transFailure; public ushort? missedSyncPackets; public ushort? numberOfResyncs; public ushort? numberOfUpdates;

The is not known as well but the stock firmware does send it after activation , i guess to set it to a known value.

The 0xAC in the power settings should be the highesr power setting of CC1110 as in the table

[xsrf]

Okay, so I can communicate with the Chroma29 on channel 0 (now with 2 slots) with offsets from 2 (868.132MHz) to 47 (868.203MHz). ~2 offsets above/below that the Chroma29 still syncs but not reliable. It may sync but fall back to wake-up channel after few syncs. When I send a cmd to it in this state (tried just sending 19 to verify connection) it clearly receives it because it stays on for about a second, but I guess it cannot decode it properly. After that it often falls back to wake-up.

Overall, I'd say communication should work in a wide range of few kHz offset.

Also... While I annotated this graph, the Chroma29 lost sync with the frequency still at 868.205MHz. But now, while I'm typing this, it actually is back in sync again. I guess the chroma29 is periodically looking for syncs on the configured channel even after falling back to the wakeup-channel (15s period).

Edit: forgot to annotate that, but you can see that the first 0x19 transmitted fine, while the others required a re-transmit

[xsrf]

Okay, confirmed, it actually re-syncs whenever I'm not looking 😅 it re-synced somewhat between 22-28min after it lost sync. Edit: and yep, I've disabled you periodic wakeup with int rounds_to_resync = INT_MAX; so it won't mess with the test.

[atc1441]

Thanks forthe in depth analysis, what i thought about jusst now after looking over it, the CC1101 in the Stock AP does uses an CC1190 as RF fron end, https://www.ti.com/product/CC1190 the Register values used in the ESP32 code are from that one, maybe that is a problem as well

Also here is an logik analyzer sniff of an Chroma29 activation, SPI Analyzer is applied. the first bid block is the Wakeup to defined channel/slot/netId for Activation then the running slots with activation and the next big block the wakeup/resync https://atcnetz.de/downloads/Full_Activation_JA10741297C.logicdata Software Saleae Logic

[xsrf]

So... You've set all the registers based on the SPI communication of the APs MCU with the CC1101? I was wondering where u got these from, since some are just set to the defaults and others write to test-registers 😉 But maybe these should be looked into... they are not default and influence the gain, IF mixer and other optimizations usually done by SmartRF Studio software:

  spi_write_register(CC1101_REG_FSCTRL1, 0x06); // IF of 152kHz (default would be 380kHz)
  spi_write_register(CC1101_REG_AGCCTRL2, 0x43); // The highest gain setting can not be used (gain is limited)
  spi_write_register(CC1101_REG_AGCCTRL1, 0x4B); // CARRIER_SENSE_ABS_THR = 5 dB below MAGN_TARGET setting
  spi_write_register(CC1101_REG_PATABLE, 0xC0); // Custom Power Amplification table
  spi_write_register(CC1101_REG_FSCAL3, 0xE9); // FSCAL by SmartRF Studio
  spi_write_register(CC1101_REG_FSCAL2, 0x2A); // FSCAL by SmartRF Studio
  spi_write_register(CC1101_REG_FSCAL1, 0x00); // FSCAL by SmartRF Studio
  spi_write_register(CC1101_REG_FSCAL0, 0x1F); // FSCAL by SmartRF Studio

It should be safe to remove them. I'll try later ;)

[atc1441]

yes this is my first time working with such low level RF i did used most of the values from the reversed firmware, but some like PATABLE and Interrupt handling i did changed to custom ones.

I also compared them with SmartRF studio to see what which one means, dont have that much knowledge to say what is right and what not.

Just as info, in the Stock AP config the CC1101 is manually calibrated before every RF action, but i guess you saw that one https://github.com/atc1441/E-Paper_Pricetags/blob/main/Custom_PriceTag_AccesPoint/ESP32_Async_PlatformIO/RFV3/cc1101.cpp#L231

So to spam this thread, i hope thats fine for everyone. if not please notify

[fearthis4]

Setting the offset freq to 15 worked for me for the chroma 74, Thanks for this, now activation works fairly consistently without issues.

[atc1441]

Just to also notify here, the Chroma29 activation and usesage works fairly relaiable with the current fix i published. very simple one...

[Kizzy426]

Hello, I am trying this out and managed to get my hands on a chroma 74 but unfortunately i cant seem to get it to work, I have access to the ESL test page and the edit page, and after spending a few days trying to figure this problem out seems i am stumped. When Arduino IDE starts i get the image below including the ip etc. after a few minutes of running i start to get these messages. I am thinking i have wired it up wrong or maybe i have damaged the CC1101 when soldering as i am no pro to this and its all new to me.

Also after trying to activate the chroma i get this error