<Degi>
Oh well, apparently you gotta order one to get schematics
<Degi>
I like e-ink because its readable independent of environment brightness and doesn't have longevity problems and uses less electricity (those cheap OLEDs can use a good bunch of power).
<azonenberg>
The LA pod will use a lot of power regardless
<Degi>
And for user-reconfigurable storage (channel colors, etc) we should use FRAM
<Degi>
Well and the e-ink is tricolor
<azonenberg>
I wasnt planning on having any persistent memory on the probe other than firmware
<azonenberg>
which we should not have to update often/ever
<azonenberg>
channel names/colors will be downloaded upon connection to the scope
<azonenberg>
and stored in ram
<Degi>
Ok then we dont need fram on there, but in the scope itself for LAN config
<azonenberg>
I will probably just use the qspi flash for config
<azonenberg>
its not something that will change often
<Degi>
Hmh yeah if it doesnt change with every use I guess thats fine
<azonenberg>
The S25FS064S has 100K P/E cycles endurance
<azonenberg>
do you know how hard it is to change the IP on something 100K times?
<azonenberg>
i'm not even going to do wear leveling or anything
<azonenberg>
it's completely unnecessary
<azonenberg>
almost all settings of interest will be volatile and just stored in ram
<Degi>
Hmm okay
<Degi>
Hm still, i'd prefer LCD or e-ink over OLED, mostly because of longevity and OLED is sometimes a bit bright to look at / looks very pixelated
<azonenberg>
So i would like to go with a domestically sourced part as well
<azonenberg>
vs something from some chinese supplier i've never heard of
<azonenberg>
not too pricey, ribbon cable connection, 56x38 mm display, white backlight, 240x160 pixels, supports spi interface
<Degi>
neat
<Degi>
Is the backlight configurable?
<azonenberg>
looks like backlight voltage is generated internally
<Degi>
Hmh does it want 15.2 V?
<azonenberg>
my interpretation is that those are all internal charge pumps
<azonenberg>
see page 7
<Degi>
It doesnt say that VLCD is generated internally tho
<azonenberg>
and 9
<azonenberg>
vlcd says "charge pump output"
<Degi>
hmh yeah
<Degi>
Ah yes
<Degi>
On page 6 you can see it
<azonenberg>
i do not see an obvious way to turn the backlight on/off though
<Degi>
"The polarizer used on the display surface is easily scratched and damaged." Maybe put a clear plastic piece over it
<azonenberg>
Yes
<Degi>
"Be careful not to touch or swallow liquid crystal that might leak from a damaged cell." lol
<azonenberg>
that is better english than the simialr warning on most lcd datasheets
<azonenberg>
"do not lick the crystal" or similar
<Degi>
lol
<azonenberg>
anyway we would need to embed a font table but i think this should be doable if we're careful
<azonenberg>
we can generate all of the text procedurally and not need a framebuffer
<Degi>
I think we have some spare 62 bytes for that?
<azonenberg>
we dont need a framebuffer
<azonenberg>
store a character table, store the text we're sending
<azonenberg>
Looks like the connector is a 28 pin 0.5mm FFC
<Degi>
Yes we could make the character table 62 bytes big
<Degi>
Nah wait
<azonenberg>
yeah
<Degi>
310 bytes
<azonenberg>
doesnt matter we have 32 KB of flash
<Degi>
Not 16?
<azonenberg>
a few tens or hundreds of bytes is NBD
<azonenberg>
let me double check
<azonenberg>
32KB flash, 4KB SRAM
<azonenberg>
stm32f031g6u6tr
futarisIRCcloud has joined #scopehal
<azonenberg>
Degi: as far as geometry goes
<azonenberg>
i'm thinking of having the LCD oriented with the long axis parallel to the probe inputs
<Degi>
yeah
<azonenberg>
as close to the inputs as possible
<azonenberg>
with the ribbon cable curving around so the contacts are on top
<azonenberg>
Using the canonical orientation of the board (probes left to right at the south side) the ribbon will come out the the north side of the display, curve around to point south
<azonenberg>
so the ribbon connector will be north of the display, with the opening on the north side and contacts on the top
<Degi>
Hm yeah that way the display can be nearer to the probe
<azonenberg>
as far as overall layout goes i'm thinking mcu, ffc, and power supply in a spine down the center
<azonenberg>
and dac
<azonenberg>
with two comparators (four channels) to the east and the other half to the west
<azonenberg>
this eliminates the need for the LVDS or input signals to cross over the digital/power area
<Degi>
Hmm
<Degi>
Maybe we can make it top/bottom too so that LVDS signals dont need to go thru vias but that probably isnt too bad a problem
<azonenberg>
the lvds should be top side only
<Degi>
So in the connector the diff pairs are only on 1 side?
<azonenberg>
the sff connector is surface mounted
<azonenberg>
WM1119CT-ND
<azonenberg>
it has through hole shield/attachment pins
<Degi>
Oh
<azonenberg>
but all of the signals are on the top layer
<azonenberg>
then the input connector is top side too
<Degi>
Of course lol. Not sure why I thought that
<azonenberg>
my planned stackup is all RF on the top, solid ground on two, split power on three, low speed control signals on four
<azonenberg>
prototype on oshpark then go to multech for higher volume using the same FR408HR stackup to avoid any need for trace geometry changes
<_whitenotifier-c>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±7] https://git.io/JfoqW
<_whitenotifier-c>
[starshipraider] azonenberg 93d0d1e - Updated MEAD LA pod design with display and different protection diodes
<Degi>
Uhh
<Degi>
Pin 2-7 are they real?
<Degi>
Uhm I think you need to use the pinout from page 6 of CON1
<Degi>
I think UC1698U is the chip
<Degi>
Or is that an example layout for a breakout board?
<Degi>
Hmh this datasheet is kind weird, but I guess yours is right
juli965 has joined #scopehal
<azonenberg>
Degi: so any other changes to suggest?
<azonenberg>
i just finished up some work for a customer, have to do some architecture review stuff for $dayjob, but i'm pretty much ready to move to the full design review
<azonenberg>
Hopefully in the next few hours i'll have a chance to make all of the pcb footprints for the new connectors, which is a prereq for the full signoff review
<Degi>
Things like input series resistors would be for the board that comes on top of the pod, right?
<azonenberg>
Degi: this is intended to be a high speed 50 ohm input so i have ESD protection and terminating resistors only
<azonenberg>
it's not protected against DC overload
<azonenberg>
CONWAY will use mostly the same circuit, but with a much more robust front end that is high impedance and much harder to kill
<azonenberg>
but trades some bandwidth for that
<Degi>
Where is D9-D12, D14?
<azonenberg>
D9-D12 are the input protection
<azonenberg>
there is no d14
<Degi>
I mean on the LCD thingioe
<azonenberg>
Oh
<azonenberg>
they're not pinned out
<azonenberg>
this module does not support the full 16 bit parallel mode for the LCD controller
<azonenberg>
only SPI
<azonenberg>
and maybe 8 bit parallel
bvernoux has joined #scopehal
<Degi>
Ah
<Degi>
Kinda looks from the datasheet like some need to be tied to vcc
<azonenberg>
it depends on the operating mode
<Degi>
Wonder if I can get PulseAudio to send differential audio, like left = - right
<_whitenotifier-c>
[starshipraider] ZigmundRat forked the repository - https://git.io/Jfo0P
maartenBE has quit [Ping timeout: 246 seconds]
juli965 has joined #scopehal
maartenBE has joined #scopehal
tverbeure has quit [Quit: Leaving]
bvernoux has quit [Quit: Leaving]
<electronic_eel>
azonenberg: sorry, don't have much time tonight to look at your updated schematics
<electronic_eel>
I'd add a tvs on the SFF8087 for uart and for 12v power
<electronic_eel>
you don't have a problem for plugging it in, because you can activate the 12v only after presence detect and some timout
<electronic_eel>
but you can get a problem when unplugging it
<electronic_eel>
there is no way to detect that early enough
<electronic_eel>
so better have all lines protected
<electronic_eel>
the lcd looks good to me
<electronic_eel>
about font storage and so on: you don't need to store any of this on the local stm32, you can transfer fully rendered bitmaps from the scope to the local stm32 over uart
<electronic_eel>
then let the local stm32 just move them from uart buffer into the lcd
<electronic_eel>
speed doesn't matter for this, nobody will change the pin names every second
<Degi>
Hmh we could run the UART at 2 MBaud and then advertise 144 Hz
<electronic_eel>
;)
<electronic_eel>
sell it to gamers
<electronic_eel>
flicker free sprite updates
<Degi>
If plug-out detection ever becomes an issue, you can add a big capacitor and then measure the voltage. But no problem here since we dont store stuff in EEPROM. Hmh maybe add TVS to all rails if there arent some, because TVS diodes could leak some excess power into the rails (though the ones we used have a builtin zener I think)
<azonenberg>
electronic_eel: we should not need a tvs when unplugging
<azonenberg>
on the 12v rail
<azonenberg>
there's a 100 uF cap on the input
<azonenberg>
that should easily absorb any spikes
<electronic_eel>
there is some current flowing, and you can get contact jitter from unplugging. this can work like a stepup converter
<azonenberg>
yeah but the dcdc's can handle up to 17V
<azonenberg>
i'm skeptical you could get enough inductive kick from just cable parasitics to turn 12V into 17V after filtering through some large caps
<electronic_eel>
I heard some reports about badly designed poe gear that was killed this way, while unplugging
<azonenberg>
tvs on the uart is a good catch thoguh
<electronic_eel>
one tvs diode on the 12v rail won't hurt
<electronic_eel>
smaj12a
<electronic_eel>
about the 1v5n converter: I still think adding a lc filter with a bigger output cap would make sense to reduce ripple there
<azonenberg>
ah yeah that was on my list and i didnt get to it
<azonenberg>
let me work on that
<electronic_eel>
no hurry, just wanted to make sure it is not forgotten
<azonenberg>
re font storage i think it would be easier if i render on the f031 but yes, worst case i can run that mcu as a dumb uart-to-spi bridge and put the intelligence and memory on the host side
<electronic_eel>
then we can render full unicode with japanese and emoji ;)
<azonenberg>
lol
<azonenberg>
we are not putting emoji in channel names
<apo>
speak for yourself
<electronic_eel>
maybe manga then?
<azonenberg>
lol
<azonenberg>
ok so tvs is being added, then a filter on the 1v5n rail
<azonenberg>
any suggestions on L/C values for said filter?
<electronic_eel>
I'd use the 22µf you have for the other dcdcs as the c-part
<azonenberg>
i actually bumped that down to 10 uF
<azonenberg>
the dcdc datasheet recommends 10 as the minimum and i have the polymer bulk cap right next to them
<azonenberg>
22uf is hard to get at 12V in ceramic
<azonenberg>
i have plenty of 22uf i can use for the filter though
<electronic_eel>
ah, I thought about the output caps, not the input one
<electronic_eel>
for the input you can use less because of the polymer
<azonenberg>
yeah i'm using 10 uF 1210 35V X5R now
<azonenberg>
for the inputs
<azonenberg>
but sure 22 for the C sounds good, what about L?
<electronic_eel>
maybe just a ferrite bead?
<Degi>
Hm yes dont use inductor type ferrites, otherwise it might oscillate a little
<azonenberg>
that was my thought. i like to use ferrites over coils for pi filters like this
<electronic_eel>
yes, it can create osciallations, also there is a self-resonance with the c, at which point the filter will be deaf
<azonenberg>
i'll go see what i have
<electronic_eel>
ok, as I wrote I don't have much time tonight, have to go to bed early
<_whitenotifier-c>
[starshipraider] azonenberg pushed 1 commit to master [+1/-0/±9] https://git.io/Jfoix
<_whitenotifier-c>
[starshipraider] azonenberg 47a4c08 - Updated LA pod schematic with additional ESD protection and noise filtering
<azonenberg>
Just pushed new schematic, assigned all footprints, and reuploaded the pdf schematic