Save Files and Colour Change Quarrelling

ProffieOS
1

I finally got round to streamlining my BladeID setups, but save files don’t seem to be entirely playing ball…

I’ve set it to run ScanID with a button push when I put a different blade in to distinguish between blades. The blades all have different resistor values, I have the SAVE_STATE define and my blade array has four stages.

I want the first three stages to work in sync, and only the fourth (which links to a charging preset) to be separate.

What I mean by that is if I have no blade fitted and I’m on preset number 6, and I then fit my test blade, run scanid to switch to the appropriate blade array, I still want it to stay on preset 6 and not switch to the last saved preset on that array. The first three preset arrays all use the same font folders in the same order.

So to do this, I’ve specified a save file for the charge blade array, but not for the other three arrays, on the basis that those three will all use the same save files which default to the top layer of the SD card.

All good so far, and seems to work great.

So going a step further, I’ve added three different PreFont folders specified in each preset array. This is so I can have a spoken ident as the bladein effect telling which array I’ve switched to. So when I insert, say, the test blade and then run scanid on the buttons, it announces, “Test blade detected,” as it switches to that blade/preset array.

But it’s here that it gets weird because I’m finding that if I start with a clean slate of no save files and just boot up and use the saber, everything works great. It switches between arrays, plays the right idents etc. But if I have done the colour change feature on any font, and I then run scanid, it still correctly switches to the correct blade and preset arrays, but bizarrely it doesn’t play the correct bladein file from the correct PreFont folder - it just plays the same one from the array I was on when I did the colour change. But I know it’s switching to both the correct blade array AND the correct preset array because my blade lengths are different in each array and they switch correctly. Also the blade styles in the no-blade array are also different to the others in order to get a kind of spinning effect inside the neopixel connector. And that all works.

So my question is, how is it managing to switch to the correct blade and preset arrays but not the correct folder paths?

The only possible clue is that on all my presets I have 12 colours all set in the same order. But the first time I use colour change, it seems to get a little confused on the order. But once I’ve cycled through the colours and saved a new colour, it seems to sort itself out and is correct after that.

So my guess is that it is indeed something to do with the save files and how they save preset and colour change data. But I’m at a loss as to how that’s creating the observed anomolies.

I’m using 7.14 so I guess the next step is to try GitHub Master and see how that compares. Will give it a go later today and report back.

Config is below.

:slight_smile:

2

You only have a different save file on your last blade, add unique ones to the others.

Example, see “blade_1_Save”,
“blade_2_Save”, etc.


BladesConfig blades[] = {
  { 10000,
    WS281XBladePtr<123, bladePin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3> >(),
    CONFIGARRAY(blade_1), "blade_1_Save" },
  { 33000,
    WS281XBladePtr<144, bladePin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3> >(),
    CONFIGARRAY(blade_2), "blade_2_Save" },    
  { 200000,
    WS281XBladePtr<1, bladePin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3> >(),
    CONFIGARRAY(no_blade), "no_blade_Save" }
};
3

But assuming I’ve understood it right, if I do that, it will save different presets for each array. i.e. if I was on preset 9 the last time I fitted the short blade, but I’m now on preset 6 with no blade, when I go back to the short blade it will flip back to preset 9, which I don’t want. I want one universal save file for all arrays except for the charge array. Which all works until I start messing with colour change.

4

Yeah, then you don’t want to use ColorChange as it’s saved in same location.

5

Ah OK - that’s what’s tripping it up then. Dang.
Thanks for clarifying.
:slight_smile:

6

You’re welcome, yeah ALL save files are shared if you don’t specify unique ones, this will go for editing as well. So if you’re wanting to use SAVE_PRESET across all IDs every thing else that saves will go with that and there’s no way to separate or specify without rewriting a ton of code for how that all works.

1 Like
7

Sounds like you’d just want to use the same save location for each blade set then, no? Maybe I read all that wrong, but like


    CONFIGARRAY(noblade), "blade_Save" },

    CONFIGARRAY(testblde), "blade_Save" },    

    CONFIGARRAY(lgt), "blade_Save" },    

    CONFIGARRAY(charging), "savechrg" }
};

?

8

Isn’t that effectively what I did originally? i.e. the absence of specified save files means it just saves all of them on the top level of the SD card?

Digging deeper, I think Fernando is right. The issue is that everything works hunky dory, but when you initiate a colour change, that’s the point at which ProffieOS writes the Presets.ini and Presets.tmp files to the SD card. And as soon as it’s done that, it has effectively nailed down the file paths and they now can’t change, even though the array driving them can. The only way they CAN change is if we have a different save file for different arrays, as that means they can then have their own Presets.ini/tmp files, in which case it switches over when you change arrays.

So it looks like my choices are:

  • Stay as I was originally and just don’t use colour change;
  • Settle for different save files for each array, but that means even things like volume will be unique to each array;
  • Settle for losing the unique PreFont idents confirming which array has been switched to, and just have a common bladein.wav for all arrays.

I’ll probably go for the last one, though I should add at this point, these are definitely first world problems and are really minor in the grand scheme. I just thought it would be nice to have that confirmation - especially as having Bluetooth on this install means I have to use Snapshot ID for the blade which isn’t quite as accurate or consistent as other BladeID setups.

9

(Or anything else that changes presets, like edit mode, or the workbench.)

No, volume is saved in the global file.

In general, it is expected that if your blade array entries use different preset arrays, then you also use different save directories. There are limited cases when having different preset arrays can share save directories, but you really have to know what you’re doing.

However, there is one more option, which is to just go hack the code until it does what you want. You could do something like make the presets.ini file contain @4 instead of the font path, and then when you read it back, you take the font path from the fourth preset. We do this sort of thing for styles since those cannot easily be saved.

You can always add an external pullup resistor somewhere.

10

Yeh, sorry, I realsied that after I posted. :confused:

Errm… this is a little over my head. Do I literally just edit the Presets.ini file and delete

new_preset
font=PreFont1;FontPrem/ANHGrfx1;Shared/Luke;Shared/Function

and replace it with

new_preset
@4

?

Yeh, that did occur to me. I’m guessing I can use any of the pins that can be used for Blade Detect (Data 2-4, RX (8), TX (9), Aux2 button 3 (22) ) as long as I specify them in the define, like this:

#define BLADE_ID_CLASS BridgedPullupBladeID<bladeIdentifyPin, 22>

On a slight tangent, one last thing that occurs with BladeID is that the absence of a blade doesn’t have a specified resistor to measure, unlike all the other blades which do have specific resistors. That said, there is still resistance measurable between LED pads and Data1 with no blade fitted, but I’m guessing that’s just from chips and stuff and not from a resistor specifically?

The other three blades all do have resistors fitted between data and LED neg. So the values I get with a meter measuring all four ‘blades’ are:

  • Hilt only - 16 k-ohms (Measured between LED pad 2/3 and Data 1)
  • Charge Plug - 21 k-ohms
  • LGT Blade - 28 k-ohms
  • Short test Blade - 61 k-ohms

But oddly, the numbers generated with ScanID under Snapshot ID don’t follow the same curve. Respectively they are:

  • Hilt only - 80
  • Charge Plug - 51
  • LGT Blade - 64
  • Short test Blade - 72

As you can see, the hilt only and the short test blade are the furthest apart in terms of measured resistance, but the closest together in terms of ScanID reading.

It therefore occurs to me, regardless of whether we use SnapshotID or BridgedPullupID, would it actually help things to wire a resistor between the LED 2/3 pads and the Data1 pad? This would give the absence of a blade a fixed resistor value which might make the readings a little more logical and consistent. I realise it would sum together with the blade resistors when a blade was fitted, but would that matter as long as we use the Proffie to provide the measurement for the config?

11

Not what I meant. Although it could work I suppose.
What I meant was that when we write the first presets.ini, it is converted from your Presets array, here:

So the idea was to do this in that function.

And the reverse when the file is read back, which happens here:

This would be appropriate if you bridge button3 with Data1.
However, what I was suggesting was to add an actual resistor between 3.3v
and Data1. If you add a 33k resistor, you would use:

#define BLADE_ID_CLASS PullupBladeID<bladeIdentifyPin, 33000>

Using a pullup resistor tends to be more accurate than bridging, and it doesn’t use up a pad on the board.

You’re not going to get the same value with a meter as when ProffieOS measures it. The electronics is active and react differently when on and when off.

SnapshotID doesn’t measure resistance. It is more of a capacitance measurement. Of course resistance also alters how fast the “capacitor” drains, so there is still some correlation. Because of how snapshotid works, it’s hard to guarantee that the values come up different for different blades. (or even with no blade.)

Maybe, maybe not.
It would alter the values, and it would alter the “hilt only” value the most. Generally I think the values would become more closely together, which could be a problem though.

The pullup resistor would do the same thing, but better, since it would pull the values further apart. It would also work with the PullupResistor<> identifier, and the values produced should closely match the actual resistors in your blades.

1 Like