MUFF WIGGLER Forum Index
 FAQ & Terms of UseFAQ & Terms Of Use   Wiggler RadioMW Radio   Muff Wiggler TwitterTwitter   Support the site @ PatreonPatreon 
 SearchSearch   RegisterSign up   Log inLog in 
WIGGLING 'LITE' IN GUEST MODE

DIY Mutable Unsuccessful Builds
MUFF WIGGLER Forum Index -> Music Tech DIY Goto page Previous  1, 2, 3, ... 84, 85, 86  Next [all]
Author DIY Mutable Unsuccessful Builds
bennelong.bicyclist
adam wrote:
i don't know - oshpark is really high spec generally, even solder mask in the vias i think.


There is a trade-off between thickness of the solder mask and the narrowness of the gaps which the mask can successfully be applied to, and the OSH Park boards have solder mask perfectly applied between the 0.5mm pitch pads of the MPU etc - which is extremely helpful when trying to solder the damn things. But the downside is that the solder mask is quite thin where it overlies traces - just try scraping it lightly with a knife, or rubbing your soldering iron against it repeatedly.

I'm not suggesting that shorts through the solder mask is the cause of your problem with your Streams PCBs, just that anyone building on OSH Park boards should think about what happens if the pot or jack socket skirts short out the traces running underneath them, and whether a bit of prevention along the lines I described above is a good idea given the overall effort that goes into a DIY build of these modules.
adam
yes, seems like a good idea
Conjure
...
gbiz
So here's how i got on with my Streams build ...

After reading all the reports here of suspected problem with the PCB from OSHPark/Adam, i expected mine would be the same. Having never used a factory Streams, I presumed both channels were identical. I was expecting identical behaviour when provided with the same signal inputs. That wasn't the case with mine. The action of chan 2 mod pot was inverted from that on chan 1 - ie to get no modulation on chan 1 the pot needed to be fully CCW, but on chan 2 it needed to be fully CW. Both modulation waveforms looked exactly like those in the User Guide, just chan 2 was inverted compared to chan 1. I couldn't find anywhere that documented this behaviour so i assumed it was part of the "chan 1 sounds different to chan 2" that others were reporting. I spent hours debugging this as an assumed h/w problem, before realising that it's how the PWM output on channel 2 is configured to work in the code. So, with a single line change in streams/drivers/pwm.cc so both PWM outputs are configured the same, both channels on mine now work exactly the same. Change line 62 to match line 55 so both lines now read
output_compare_init.TIM_OutputNState = TIM_OutputState_Enable;

Once i got that out of the way, everything else appears to be working as i'd expect, though as i say, i don't have a factory module to compare against.

As this one is now working, I doubt there's an issue with the PCBs from Adam. Or at least certyainly not with the one i have here.

For any of you chasing differences between the two channels & who are seeing the same behaviour between the two mod pots in VCA mode, i'd suggest you give that code change a try. Assuming you have the build environment setup, it's trivial to implement & test.


I'm kicking myself for only buying one panel from Greyscale now. This is really great sounding module. I'd happily build a couple more. The one addition i'd really like is CV control for shape & mod. Maybe something to hack up on another one hihi
adam
another mystery solved smile
gbiz
Well, it's one down anyway hihi
mckenic
applause
Thank you!
pld
Are you sure that's right? It should probably be either:
output_compare_init.TIM_OutputState = TIM_OutputState_Enable;
or
output_compare_init.TIM_OutputNState = TIM_OutputNState_Enable;
which are subtly different bits in the registers.
gbiz
Very possibly. I've done no Arm programming, i was assuming that the existing code was correct. If you look at the existing code on github, line 55 has the same initialisation that i just copied
https://github.com/pichenettes/eurorack/blob/master/streams/drivers/pw m.cc

As i said, it does achieve what i was looking for, the same PWM behaviour on channel 2 as channel 1.

From what you've said it sounds like i need to look at this a bit more.
sixty_n
If you make a DIY braids the encoder works backwards, maybe it's a similar thing to that but it's weird it's just one not both. The code in pwm.cc explicitly sets up one channel as different to the other. This must have been done for a reason but I can't think what it would be. I thought the pwm.h file might shed some light on this but it doesn't
Altitude909
sixty_n wrote:
If you make a DIY braids the encoder works backwards, maybe it's a similar thing to that but it's weird it's just one not both. The code in pwm.cc explicitly sets up one channel as different to the other. This must have been done for a reason but I can't think what it would be. I thought the pwm.h file might shed some light on this but it doesn't


Simple. The production encoders have a different pinout
sixty_n
yes but this is suggesting that on the production versions the channel 1 pot has a different pinout to the channel 2 one
Altitude909
Well, I dont know what the issue with streams is, I'm only referring to the Braids encoder.

Has anyone successfully built one? If they are all bad then there might be a fab problem where the boards on the git are spec'd higher than the fab can make
gbiz
Altitude909 wrote:
Well, I dont know what the issue with streams is, I'm only referring to the Braids encoder.

Has anyone successfully built one? If they are all bad then there might be a fab problem where the boards on the git are spec'd higher than the fab can make


See Adams post on page 1. Nobody had built a successful build. Everyone was reporting differences in behaviour between the two channels. As everyone had experienced it, the finger of blame was being pointed at the boards, especially as OSHPark had had to increase the drill size. I went into debugging my build assuming it had the same issue with the board.

We're talking about a 10K pot here, one side at 0V, the other 3.3V, & the wiper going straight into the MCU. Simple as it can get. I can't see the two outer pins being swapped.

There are some vias that i have to say do look dodgy, but they all buzz out fine. The only issue on my build is the inverted behaviour of one PWM output. Now thats resolved (correctly or not), my board appears to be functioning 100%. Putting identical signals into both channels, monitoring the output with headphones, there no discernable difference between them.
pichenettes
The factory made modules work as expected (no channel swap) and do not require fancy pots.

I'm surprised that you found it necessary to fix PWM channel 4 (second channel of Streams), while the problem is obviously with channel 3 (first channel of the module). With the module in envelope mode, shape set to linear, LEVEL set to maximum, and a sawtooth wave in the input, the MOD knob should do a filter sweep from 12 o'clock to 5 o'clock.

The code for initializing OC3 in pwm.cc is indeed fishy BUT if you look at the actual implementation of TIM_OC3Init from ST, both TIM_OutputNState and TIM_OutputState are both shifted left by 8 and OR'ed to CCER, so my incorrect code still puts the right value in the right register, and worked well so far on hundreds of modules. Weird!

It could be that different compiler versions lay out the code differently in memory and output_compare_init isn't filled with the same garbage on the version you are using? Or that the parameter checking assert is enabled and that the function fails to initialize the channel because of the wrong bitmask being used.

Anyway I've pushed a fix in which all the necessary fields of the struct are initialized with sane values.
adam
thats very kind of you olivier, thanks smile
gbiz
Oh cool. Thanks pichenettes. I'll give it a try.

I picked Streams channel 2 as to me the behaviour of the Streams channel 1 modulation pot was "right" - move the pot clockwise & the filter opens up. (I did all my testing in green LED #1 VCA mode).

I did wonder if it was something odd with the compiler. I used the same toolchain as i've used for a number of modules - gcc-arm-none-eabi-4_8-2013q4. I then tried arm-none-eabi-gcc-cs-4.9.2-3 which is the latest available for the Fedora 20 system i'm running this on. Both exhibited the same.

I still have the older 4.8.3 toolchain tree here, maybe i should have tried that ?.
gbiz
New code built & installed & both mod pots are working as expected.

Again, many many thanks for your help pichenettes.
pichenettes
The firmware for the STM32F1 modules are built with 4.5.2. It's what was "current" at the time I developed Braids, and Braids' code has become so touchy regarding flash size that I never moved to a newer version. The F4 projects are built with 4.8.3
gbiz
I was aware of that issue for Braids & i've done that for Braids. I didn't realise it applied to all your F1 modules. Noted for future builds.

"make size" with both compilers suggested there was plenty of room free, so i assumed it'd be OK using the later compiler.
pichenettes
There shouldn't be any problem using a more recent toolchain for the other projects... except when there's a strange corner case like that!
koerby
Thanks pichenettes, now it works in a perfect way
pichenettes
Once I'm back from vacations I'll make a vagrant environment with all the right tools to make it easier to build the code.
adam
thanks, i think that'd really help people, seems like setting up the toolchain in the first place can be a huge barrier, especially if people are new to the command line
dropmotif
Thanks pichenettes and thanks gbiz for your help!
It's working fine now.
MUFF WIGGLER Forum Index -> Music Tech DIY Goto page Previous  1, 2, 3, ... 84, 85, 86  Next [all]
Page 2 of 86
Powered by phpBB © phpBB Group