#249

config.txt as a framebuffer_priority, perhaps this could help?
https://www.raspberrypi.org/documentation/configuration/config-txt/video.md

yeah, so I can add to the api, but I want it to do something ‘reasonable’ by default, as otherwise it will become a support issue.

ok, so it sounds like my current behaviour might be pretty reasonable,
which is to take the ‘last’ framebuffer device thats available.
e.g. take /dev/fb1 if it there, if not use /dev/fb0
certainly this is working on the PI3 and PI4

that said, I don’t have any mini HDMI adapters to use the HDMI outputs on the rPI4 :slight_smile:
have you got one, when its plugged in, does it push fates to /dev/fb1
(if so you might want to test this on my 0.91 release … it should still work)

what is going to be a bit odd about all this, is I thought the x config tended to have the framebuffer in it, so not sure how that works if its ‘dynamic’

#251

Aha, that’s probably it. IIRC i expressed interest in a kit, so that would make sense. I’m just getting a little excited is all :laughing:

1 Like
#252

Yes - I have tested with the mini-hdmi on the port closest to the front. Yes - it pushes fates OLED to fb1

I’m laser cutting cases now for a few hours and then need to get a bike ride in… so it’ll be later this evening (US central timezone) when I have a chance to install your new version and test.

3 Likes
#253

Got mine built, but strange issue. When I plug it in, I can see the green light flashing and that pi boots every time. If I move encoders and click buttons I can see the green light on the pi flashing and it’s clearly doing something. However, only about 1/2 of the time does the screen turn on. I thought it might be the LCD connections (resoldered all headers and pins) but, with everything screwed down, no movement, if I unplug and plug back in once or twice the LCD comes on. In addition, once it is on, I can shake the box around and the LCD keeps working w/o an issue. Maybe a bad LCD?

#254

Which Pi are you using?

Whats your power supply? You absolutely need a 2.5A rated supply for a 3b. A pi4 will work ok with a 2.5A supply most of the time, but a 3A supply is what they recommend.

Soldering - make sure all the thru-hole pins have a good solder joint - especially on the raspberry pi header. When in doubt - Reflow them again.

Bad OLED? Maybe? If it persists or stops working altogether, you could call the place you bought it (Mouser is pretty good about replacements for failed units). BUT - you’d want to be pretty darn certain the display has failed and its not just bad soldering.

#255

Hey Builders!

If you’re looking for the BOM - the Mouser cart link is NOT UP TO DATE with whatever stock is currently available.

Please be sure to use the github BOM as your main source of information. I have updated that list with alternate part numbers as I find stuff being out of stock.

Black Button caps look like they are out of stock at mouser, but digikey has 100+
https://www.digikey.com/products/en?keywords=1US09

4 Likes
#256

Also an UPDATE:

Bare PCBs are now available for sale in the shop.

Acrylic Case kits are in short supply and I’m doing small runs when I have time. If you want a case, please email me from the shop before you make your pcb order and I’ll give you more information.

SMD-assembled pcbs are in! But I need to figure out a testing procedure and get them prepared. This also means kits will start happening soon as well. I’ll update again later in the week with more info.

16 Likes
#257

Woo! Sounds like soon it’ll be time to talk to my library about printing a case…

Sorry if this is a dumb question, but I’m still a little unclear about when the USB-C jack is needed or useful. Is it mainly for the RPi 4, as an alternative to its nonstandard jack? If so, will you be offering SMD-assembled PCBs without it?

And: are you planning on including encoder knobs with your kits?

#258

You can power Fates from either the pi power input or the USB-C jack on Fates (works the same with pi3 or pi4)

I prefer having all the cables coming out of the back. If you use the pi power input that cable comes out the right side.

Not sure what you mean about the pi4 having a non-standard jack. It’s usb-c. (But the early pi4s won’t take power from some “e-marked” cables - and I’ve fixed that with the fates power input)

Smd-assembled boards and Kits will have the usb-c hack already soldered on. You can just ignore it if you don’t want to use it. (Or diy from a bare pcb if you really don’t want it)

3 Likes
#259

Thanks! yeah, that’s what I meant – I know it’s not the jack itself that’s nonstandard, but I saw lots of people complaining about various power supplies not working when I googled “raspberry pi usb-c” when I was trying to understand what it was for. Makes a lot of sense to want all the cables on one side of the unit, and if it works for all Pi models then great. I’m not sure now why I imagined otherwise.

#260

FWIW I use a little usb-micro to usb-c adapter on my pi3 unit.

2 Likes
#261

Would there be any benefit to using a pi4 as opposed to a pi3? A pi3 would be more powerful than an off the shelf norn’s, correct?

#262

Forgot to answer this - yes. The encoder version of these knobs

I did an informal poll on instagram and everyone liked the ones on the left here (on the white case)

I believe the pi3b+ has a bit more processor speed than the stock CM3. So yeah. that’s already a bit more power. The pi4 gets you a bit more processor than that and the option of more RAM - which might only matter for loading huge samples?

Either will be great for norns. Which is better for your specific use case? I dunno ¯_(ツ)_/¯

4 Likes
#263

I’ve a question about the encoders. They works without glitches except when I turn them really fast. In this case they stop scrolling. Is this normal? I’ve never touched a Norns so I don’t know if something screwed with my build or it’s his regular behaviour.

#264

I’ve not noticed this on my fates…

Is it only on one particular encoder, or all of them?
(if you have install Orac, does it happen there as well, or just in the norns software?)

which rPI are you using? 3b, 3b+ or 4?

are you on the latest norns software version?
(monome have tuned/improved the way the encoders have reacted over the various releases as some users had issues)

I’d personally think its most likely software, given it only happens at ‘speed’,
(though it could be a faulty encoder?)

if it’s on all encoders, its seems unlikely you would have multiple faulty encoders or soldering issues.

if it’s on one encoder, and its easy to do … I’d probably look over the solder joints, perhaps a dry joint -so just reflow them (heat it up joint again), also look at the header pins to the raspberry pi for same issue.

1 Like
#265

all of them. I’m using a 3b+ with this image disk (norns 190930)

#266

I think that is a hardware problem, the encoders are connected directly to the Raspberry GPIOs.
The encoders should be connected like the image.
Encoder%20Circuit
Without this circuit the encoder could be not readable at high speed turns (noises, parasitic voltages, etc.)

@okyeron consider to implement the circuit in futures versions of the Fates board.

1 Like
#267

so like how fast are we talking here? I’ve not run into this (or noticed it) since I started on this project more than a year ago. (Not to say it’s not a potential issue)

It could be the norns software doing something with the encoder readings or it could be due to the hardware not keeping up as @Oxbown made note

Would you pm me any links or references for that circuit? I’d like to read more about it. The various example circuits I looked at for pi or other modules (like MI Braids or Yarns) do not have this type of circuit.

#268

It’s a debouncing circuit. Switch debouncing can be done either in hardware or software. Both approaches are well explained in this series of articles https://hackaday.com/2015/12/09/embed-with-elliot-debounce-your-noisy-buttons-part-i/

6 Likes
#269

Braids and yarns debounce in software - see drivers/encoder.h and .cc

3 Likes