Trying to get Cement library to work with bracelets

[logicallysynced]

Hi there, I have about 10 bracelets of EU model Cement 1.1 that I'm trying to test this library with (fresh batteries by the way). I'm using a Mega 2560 with no level shifter.

I'm having some small success with your basic.ino file, if I send a CLI command:

1 - black, wakeup! and then 3 - gold, fade in, fast

the bracelets wake up after about 10 seconds and light up gold and fade in and out. I've tested all the CLI commands and the only commands that seem to respond are:

1 - black, wakeup! 3 - gold, fade in, fast c - blue, fade, random slow g - white, fade in, fast h - test-signal

all the others do nothing.

Ultimately I'm trying to send a custom RGB and FX value to the bracelets programatically, and it seems your Pixmob_Cement library is perfect for this - however your example doesn't seem to do anything to my bracelets.

I just get "done" in the console and no bracelet activity.

`/* testscript for PixMob waveband - (RF enabled crowd pixel)

library - edition

2024 sueppchen, Serge_45

TX: arduino pro micro /ATmega32u4 levelshifter cc1101 radio module

send custom color with attaack and release */

define RED 255 // 0 - 255

define GREEN 255 // 0 - 255

define BLUE 255 // 0 - 255

define ATTACK 1 // 0 - 7 (0 = fast)

define HOLD 7 // 0 - 7 (7 = forever)

define RELEASE 0 // 0 - 7 (0 = background color)

define RANDOM 0 // 0 - 7 (0 = no random)

define GROUP 0 // 0 - 31 (0 = all batches)

// ------------ global ------------

include

// ------------ I/O ------------

define CLI_SPEED 115200 //ATmega328 = nano, Mini Pro

define TX 6 // data output

// ------------ TX ---------- Pixmob batch;

// ------------------ SETUP ------------------- arduino setup
void setup() { //SETUP

Serial.begin(CLI_SPEED);                     // debug
delay(3000);
batch.begin(TX);

Serial.println("done");
delay(1000);

batch.setFXtiming(ATTACK, HOLD, RELEASE, RANDOM);
batch.sendColor(RED, GREEN, BLUE, GROUP);
}

//

// ------------------ MAIN -------------------- void loop() { batch.refresh(); delay(40); } `

Do you know what might be causing this? Any help in the right direction would be very much appreciated.

[sueppchen]

ok, while the basic_color.ino (--> example) script is working here - lets find the difference between us:

I am using pro mini (leonardo) ATmega32u4 I am using Texas Instruments CC1101 board with level-shifter my batches are EU-version

connected hardware-SPI with SlaveSelect=10, TX=7

edit: my test-batches have 5V input and not the batteries in use

what is your wiring?

"done" is send when INIT is done, because I had sometimes issues when with my CC1101 or my ttyUSB hanging.

do you have a possibility to check the output timing (logic analyzer or something like that) ?

[sueppchen]

you can not use "hold forever" and "background color" together.

try the example as it is and then change the values...

often the batch is not used with full brightness to save battery life. so when you send 100% white you draw 120mA power only for the LEDs(20mA each LED) - the inner resistance of the batteries will drop the input voltage under operating level and the batch restarts...

[logicallysynced]

I’m not using a level shifter currently (got one on order) and I don’t have a logic analyzer unfortunately. Mine are EU batches also.

My CC1101 is a E07-M1101D-SMA. It’s wired as follows:

The code was updated to use pin 6 as is highlighted, however I’ve also tried pin 7 with no difference.

Given that basic.ino partially works (as mentioned earlier) for lighting up to gold, blue or white - my thought was the wiring should be mostly okay?

I’ve tried a number of different values together on the code example, I’ve even tried removing the FX line and only sending the setColour. I’ve also tried the code as is originally there to no avail.

[logicallysynced]

As an update, I've had some partial success. It suddenly started working when I removed the if (ELECHOUSE_cc1101.getCC1101()) { check.

However the results seems really hit and miss when using basic_color.ino compared to basic.ino. I can sometimes get some of the bracelets to light up but not all of them usually - whereas with basic.ino they all light up consistently.

I've got a level shifter coming today so hopefully that might solve some of the buginess, but will report back.

[logicallysynced]

While I’m working on the other stuff, I wanted to ask:

void valueInput(){ // get plain values index=0x0; Serial.print("1 mode (0-3f)"); byteArray[2][1] = ((uint8_t) readCliHex() ) & 0x3f; Serial.print("2 green (0-3f)"); byteArray[2][2] = ((uint8_t) readCliHex() ) & 0x3f; Serial.print("3 red (0-3f)"); byteArray[2][3] = ((uint8_t) readCliHex() ) & 0x3f; Serial.print("4 blue (0-3f)"); byteArray[2][4] = ((uint8_t) readCliHex() ) & 0x3f; Serial.print("5 attack (0-7)"); byteArray[2][5] = (((uint8_t) readCliHex() ) & 0x7) << 3; Serial.print("5 random (0-7)"); byteArray[2][5] += ((uint8_t) readCliHex() ) & 0x7; Serial.print("6 release(0-7)"); byteArray[2][6] = (((uint8_t) readCliHex() ) & 0x7) << 3; Serial.print("6 hold (0-7)"); byteArray[2][6] += ((uint8_t) readCliHex() ) & 0x7; Serial.print("7 Group (0-3f)"); byteArray[2][7] = ((uint8_t) readCliHex() ) & 0x3f; } void plainInput(){ Serial.print("input mode (0-3f)"); byteArray[2][1] = ((uint8_t) readCliHex()) & 0x3f; Serial.print("input green (0-3f)"); byteArray[2][2] = ((uint8_t) readCliHex()) & 0x3f; Serial.print("input red (0-3f)"); byteArray[2][3] = ((uint8_t) readCliHex()) & 0x3f; Serial.print("input blue (0-3f)"); byteArray[2][4] = ((uint8_t) readCliHex()) & 0x3f; Serial.print("input rise (0-3f)"); byteArray[2][5] = ((uint8_t) readCliHex()) & 0x3f; Serial.print("input fall (0-3f)"); byteArray[2][6] = ((uint8_t) readCliHex()) & 0x3f; Serial.print("input group (0-3f)"); byteArray[2][7] = ((uint8_t) readCliHex()) & 0x3f; }

for the rise, fall, attack, release, etc. - what does the 0-3f and 0-7 equate to? Is this HEX for the seconds?

[sueppchen]

ok, I am back but I really can not help you - because I do not have your setup to test the stuff. (I do have many arduinos but there is no ATmega256 which has more peripherals than other ATmega chips. you can check if the hardware-spi has the same pins... maybe have a look at the Pixmob::begin( ...) function in the library and adjust the pins to your need. the if(ELECHOUSE_cc1101.getCC1101()){ check is to be shure the communication is ok. so if that fails your SPI-wiring has some faults. check that. you wrote that you used the CC1101 without levelshifter - maybe you killed it. it is only 3.9V on every pin. --> see datasheet page 8, table 1 ,,Absolute Maximum Ratings" "Under no circumstances must the absolute maximum ratings given in Table 1 be violated. Stress exceeding one or more of the limiting values may cause permanent damage to the device."

try the advanced.ino from root directory of the project. there you can send custom values.

a table for the rise/ hold and release values can be found in the wiki.

[logicallysynced]

I ended up getting this working, using a level shifter and a new CC1101.

It only works when the bracelet is like 10-20 cm in range of the antenna - which isn’t ideal and it’s pretty spotty too. My guess is the antenna included with the CC1101 isn’t designed for 868Mhz. I’ve ordered a new one off Amazon though which is specifically designed for it - hopefully that’s the range issue.

Thanks for all your help troubleshooting though.

[sueppchen]

if you have an VNA you could rematch the antenna section. there is a reference in the datasheet at page 25 and 26.

the frequency is actual only a guess with integer multiplicators of the XTAL. I have not been on a pixmob even to check that since I started with this project.