PB V3.7 beta test thread

Proffieboards
82

Confirmed same sound issue using my MacbookPro to compile and upload.

83

The more I think about this, the weirder it gets too.
Iā€™ve been thinking that this is a race condition that only occurs when things are running fast. However, style doesnā€™t run every loop of the main loop. Most of the time weā€™re just waiting for the previous blob of data to be fed out to the blade.

Could you try if a super-simple style, like StylePtr() still causes this problem?

84

error: no matching function for call to ā€˜StylePtr()ā€™
Trying StylePtr<Black>() instead
EDIT Probably what you typed but the site modified

85

That is in fact what I typedā€¦

86

It does not. It plays cleanly with that style.
I am currently installing everything on a Windows 10 Virtual machine for variety testing.

87

Same result uploading via virtual Windows 10.

88

Ok, flashed my test board with a config from the new configurator, used SDIO High Speed.

On MacOS, copying files to the SD card via usb is still only running at the original speed of roughly 300-500 Kbps. Donā€™t have a PC to test right now, but curious what speeds I should be expecting?

1 Like
89

I wonder if there is maybe something about the power handling for blades that is messing with the sound.

That leads to an additional two things to try:

StylePtr<InOutHelper<Green, 800, 300>>()   // Does this work?

The other one is your style that you pasted above, but without the on-demand battery layer.

90

The USB read/write speed really isnā€™t expected to be all that much higher than before.
The real benefit of SDIO is to support more audio streams and other things that require high bandwidth, like color screens.

91

Ah, ok. I had thought I read somewhere that transfer to the SD card over USB would also be improved. Thanks!

92

Well, didnā€™t get very far tonight but thereā€™s always tomorrow. Going to put together one of the v2 Graflex Helper boards and test with the new dedicated pads for remote USB tomorrow.

1 Like
93

Yes, thatā€™s clean.
Now, the default file has 2 styles per preset.
The above works fine with both as that same style.

I found something interesting.
So the default bladeconfig array has
first blade - WS2811BladePtr<97, WS2811_800kHz>(),
2nd blade - SimpleBladePtr<Creeā€¦stuff

Depending on how I order the styles in the preset makes it work or not.

my style w/ NO batt-level layer
InOutHelper style

Good
Adding batt-level layer back in also Good.

So I tried

StylePtr<Black>(),
mystyle

This sounds worse, actually just a blip of out.wav, then no sound until last 1/2 of in.wav

So then I flipped them

mystyle,
StylePtr<Black>(),

and itā€™s good.

Lastly, I brought a RgueCmdr Rainbow preset into MY config and it had no issues (I had to add 3 more dummy blade styles) because bladeconfig array has:
WS281XBladePtr<
WS281XBladePtr<
WS281XBladePtr<
SimpleBladePtr<
SimpleBladePtr<

So is there something about the
WS2811BladePtr<97, WS2811_800kHz>(),
in the default config orā€¦?

94

Ok. Itā€™s the SimpleBladePtr<Cree..... blade array somehow is an issue.

I did the default_proffieboard_config from scratch with NUM_BLADES 1
and commented out the 2nd style in all presets and the
SimpleBladePtr<Cree..... blade array, leaving just
WS2811BladePtr<97, WS2811_800kHz>(),

Every preset sounded fine.

I swapped blade arrays, leaving only the
SimpleBladePtr<Cree.....

Lo and behold Everything was bad, same as in all other tests before.

Then just to confirm, I changed the RgueCmdr test preset in MY config file where only the last 2 blades out of 5 are SimpleBladePtr< 's
I had only brought over the top 2 styles from the default, and filled in the bottom 3 styles with ones from elsewhere in the config, so it was:

{ "RgueCmdr", "tracks/mercury.wav",
  StyleRainbowPtr<300, 800>(),
  StyleRainbowPtr<300, 800>(),
// Switches
  StylePtr<Stripes<16000,100,Red,Black,Green,Black,Blue,Black,White,Black,Rainbow,Black,Yellow,Black,Rgb<60,0,255>,Black>>(),
// Pommel
  StylePtr<Layers<Pulsing<Blue,Black,200>,InOutTrL<TrInstant,TrInstant,Pulsing<Blue,Black,2500>>>>(),
//Bluetooth
  StylePtr<Blue>(),
  "rainbow"},

which sounded fine.
When those Rainbow styles hit the SimpleBladePtr< with:

{ "RgueCmdr", "tracks/mercury.wav",
    StyleRainbowPtr<300, 800>(),
    StyleRainbowPtr<300, 800>(),
    StyleRainbowPtr<300, 800>(),
    StyleRainbowPtr<300, 800>(),
    StyleRainbowPtr<300, 800>(),
  "rainbow"},

It had bad sound again.

Also, keeping this tied to this V3 board beta test thread, this same test works fine on a 2.2 board.

95

Dumb question: What do you have hooked up on LED3/4/5?

96 
{ NO_BLADE, // 1" Ciel_Tan_A 132 
  WS281XBladePtr<132, bladePin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3> >(),// Main Blade
  WS281XBladePtr<5, blade2Pin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3> >(),// HiltPCB
  WS281XBladePtr<11, blade3Pin, Color8::GRB, PowerPINS<bladePowerPin5> >(),// Switches mini strip
  SimpleBladePtr<AccentsLED, NoLED, NoLED, NoLED, bladePowerPin1, -1, -1, -1>(),// Pommel
  SimpleBladePtr<CH3LED, NoLED, NoLED, NoLED, bladePowerPin6, -1, -1, -1>(),// Bluetooth
CONFIGARRAY(noblade),
"00_NO_BLADE_save"},
97

Note, my first post about this issue posed this question.
So is that a thing?
But when MY config is used, with the appropriate blades configā€™d for the install build, still has issues when a Rainbow blade style is applied to the SimpleBladePtr?

Also, the switches area mini-neostrip was added after this first showed up.

98

Having a config file that is completely different from what you have plugged in can do some weird stuff. Itā€™s rarely harmful, but it is possible for it to be harmful. An example would be to have a high-powered blade plugged in while only turning on one FET instead of two.

In this case, weā€™re potentially feeding an 800Hz PWM signal into a neopixel strip. That might cause 800Hz of werdness coming back through the data wire, or pull 800Hz through the + wire for that neopixel strip. Iā€™m not entirely certain what that would do.

Still, it could just be the speed of evaluation that is causing problems. SimpleBladePtr<> only has one LED, which makes it very fast. However, we should be able to narrow things down further by trying the following blades:

WS2811BladePtr<1, WS2811_800kHz>()  // also fast

or

   SimpleBladePtr<CreeXPE2WhiteTemplate<550>,
                    CreeXPE2BlueTemplate<240>,
                    CreeXPE2BlueTemplate<240>, NoLED, bladePowerPin1, bladePowerPin2, bladePowerPin3, -1>(),

This last one should be equally fast, but flips different pins.

1 Like
99

Okay. Iā€™ll try these tomorrow. Note that I have been testing with no blade inserted.

1 Like
100

Assuming you meant as replacements for the 2nd blade, using this:

BladeConfig blades[] = {
 { 0, WS2811BladePtr<97, WS2811_800kHz>(),
      WS2811BladePtr<1, WS2811_800kHz>(),
     CONFIGARRAY(presets) },

and then trying this:

BladeConfig blades[] = {
 { 0, WS2811BladePtr<97, WS2811_800kHz>(),  
     SimpleBladePtr<CreeXPE2WhiteTemplate<550>,
                    CreeXPE2BlueTemplate<240>,
                    CreeXPE2BlueTemplate<240>, NoLED, bladePowerPin1, bladePowerPin2, bladePowerPin3, -1>(),
     CONFIGARRAY(presets) },

Everything sounds normal with both of those versions of the bladeConfig.

1 Like
101

To me, this indicates that the problem is one of LED4, LED5 or LED6.
Basically, it seems that whenever you have a SimpleBladePtr<> that output PWM to those three, then the sound gets messed up.

I suggest taking this one:

and then replacing one at a time of bladePowerPin1/2/3 with bladePowerPin4/5/6 and see when the problem starts appearing.

Itā€™s either because the accent neopixels are causing interference, which is probably normal, or because of some sort of short, which is not.

1 Like