<DocScrutinizer05>
well, you know I always love to read (and comment on) new schematics, but I'm not git's greatest fan
<wpwrak>
it works rather well :)
<wpwrak>
and especially if you use it for reading ;-)
<wpwrak>
but now the schematics are behind whatever ailment the qi-hw servers have this time :(
<DocScrutinizer05>
size of device sounds a tad.. huge?
<wpwrak>
about 3 x 8.5 x 1.5 cm. a but smaller than my samsung x830.
<wpwrak>
the height is determined by battery and wheel. they'd on opposite sides. if i wanted them on the same side, the surface would have to grow
<wpwrak>
the width is determined first by the display and then by the wheel. the wheel is already relatively small.
<wpwrak>
the length is mainly determined by layout density. for prototyping, i want a DIY-able design, so density is low.
<wpwrak>
but even with multilayer, BGA, and so on, there wouldn't be a LOT you could take away. maybe 1 cm, 2 cm if the rest is to be very crowded (wheel touching the display so it'll be hidden behind your fingers)
<DocScrutinizer05>
mhm
<DocScrutinizer05>
1.5cm for battery?
<DocScrutinizer05>
can't you use CR2532?
<wpwrak>
CR2032. that's 3.2 mm plus about 0.5 mm for clip and tolerance. then 1 mm plastic wall.
<wpwrak>
above it is the PCB, 0.8 mm. on the PCB is the wheel, 5 mm.
<DocScrutinizer05>
ooh
<wpwrak>
so that's 5 + 0.8 + 3.2 + 0.5 + 1 mm in total
<wpwrak>
hmm. 10.5 mm. lemme check :)
<DocScrutinizer05>
2 walls
<wpwrak>
ah yes, 10.4 mm. not 14 mm :)
<wpwrak>
only one - the wheel goes to the surface
<DocScrutinizer05>
so the battery area is so large it can't stay clear of wheel?
<wpwrak>
the wheel is 22 mm, the battery 20 mm, the display 35 mm. you'll want a bit of space between display and wheel. and the antenna needs a bit of room as well, at least 5 mm.
<wpwrak>
then add two double walls. so having it all on the same side would make it ... 88 mm plus the wheel-to-display space
<wpwrak>
and then there's the power switch. as fat as the battery.
<DocScrutinizer05>
err, when wheel and battery are different place then how will their ... I don't get it
<wpwrak>
you can either put them side by side or one on top and one on the bottom
<wpwrak>
you also have a display that goes on the same side as the wheel
<DocScrutinizer05>
when 5mm wheel and 3.2mm battery add up to heght, then battery and wheel are stacked and I dunno why they would be
<wpwrak>
correct. that way, i don't get a huge surface
<DocScrutinizer05>
I thought you could place battery under display
<wpwrak>
else, i'd have to make the device a fair bit longer.
<DocScrutinizer05>
assuming that display is <5mm
<wpwrak>
the display is quite thin, 1.6 mm
<wpwrak>
needs clearance (at least for tolerance) above and below, and also the top plastic (it's too fragile to be exposed)
<eintopf>
hello
<DocScrutinizer05>
I'm quite sure you know how to stack a ME. But it seems I can't imagine what it looks like
<wpwrak>
so that's about 3 mm for the display. i also sneak a few components under it. they have about 2 mm maximum vertical room, preferably a little less
<roh>
hm. do you have a cad file?
<wpwrak>
nothing complete yet
<roh>
maybe something simple like in openscad.. just to visualize
<wpwrak>
top has, from left to right: antenna, display, a LED, wheel
<wpwrak>
bottom has: inaccessible space under wheel, battery, switch, usb, uSD, keep-out area under antenna
<eintopf>
how do I programm the mcu without dfu?
<wpwrak>
which mcu ?
<eintopf>
oh I thought there is some mcu on this :)
<wpwrak>
ah :)
<DocScrutinizer05>
hmm, I had placed the battery under display
<DocScrutinizer05>
I.E. between display and PCB
<wpwrak>
yes, there is. for the initial programming, via SWD (a reduced JTAG) on the large test points
<wpwrak>
there's not enough room here :(
<wpwrak>
also, access to the battery would be difficult
<DocScrutinizer05>
slot-in
<wpwrak>
messy :)
<DocScrutinizer05>
nah
<wpwrak>
and the stack would get too height, so the whell would have to be raised
<DocScrutinizer05>
3.2mm plastic block with 20mm hole in it
viric has quit [Ping timeout: 240 seconds]
<wpwrak>
you need something on top that pushes the battery onto the pcb contact
<DocScrutinizer05>
makes for nice slide to push in / pull out the battery, and same time creates a flush surface of case
<wpwrak>
also, you'll hit the display connector
<DocScrutinizer05>
sure, you use a steel spring for that rougjly M shaped
<wpwrak>
i can't make such parts :(
<DocScrutinizer05>
this isn't too hard. But you can find such thingies in other chinese 1$ toys
<wpwrak>
my solution is some unpleasantly soft metal that wraps around the battery and that is supported by the cover. works okay-ish but would fail in a more demanding setup
<wpwrak>
yes, all the toys have their very nice custom-made battery contacts
<wpwrak>
and all you can find off the shelf are some monstrosities
<wpwrak>
with the battery in that area, the layout would probably become unroutable for DIY
<DocScrutinizer05>
even more easy: slot in pcb, solder a L shaped spring wire on long end to opposite side of PCB so that short arm of L goes thru the slot in PCB, then push outer small side of battery against it
viric has joined #qi-hardware
<roh>
nah.. just use a readymade battery holder. developing your own without a team of seasoned me is madness imho
<wpwrak>
roh: i think there's no choice. the ones you find at the usual shops are huge. but you don't have to design it from scratch, of course.
<DocScrutinizer05>
make the hole in plastic block a pit (sorry missing the english term for "sackloch") and place some elastic foam or spring in it
<roh>
wpwrak: true. most are 'huge'
<wpwrak>
a battery-sized slot would again make the design unroutable
<roh>
ive seen some quite flat ones too. intended for used standing up
<roh>
one could mount them on the edge of the pcb at one end, and use them as slot-in from the side
<DocScrutinizer05>
huh, nobody said "battery sized" - just 2 mm to allow for some spring load
<DocScrutinizer05>
when inserting battery
<wpwrak>
roh: i experimented quite a bit with CR2032 holders. most of them need excessive force. they're basically designed to hold the battery without any mechanical support from the case.
<wpwrak>
roh: and even the smallest ones eat a lot more space than just the battery plus a contact
<roh>
wpwrak: true. any way.. i guess thats the most difficult part to solve besides trhe display cover
<wpwrak>
DocScrutinizer05: you mean a spring parallel to xy for the bottom and a spring parallel to xz for the top/side ?
<wpwrak>
then you need a roof against which you can push ...
<DocScrutinizer05>
yes, you could put it that way
<DocScrutinizer05>
the roof would be the display, no?
<DocScrutinizer05>
but I already improved Version1
<wpwrak>
no mechanical load on that fragile little thing, please :)
<roh>
hehe.. now you know why i asked for a drawing ;)
<roh>
what kind of display is it? and where to get it cheap?
<roh>
usually one does hasl finish then, adding gold
<wpwrak>
roh: and you haven't seen the insertion force of these things :)
<DocScrutinizer05>
roh: I already suggested that, he doesn't like it
<roh>
wpwrak: well.. smaller than the ones with a plastic holding the other pin
<wpwrak>
roh: yes, a medium-sized dinosaur is smaller than a whale ... ;-)
<DocScrutinizer05>
how's insertion force a problem?
<wpwrak>
DocScrutinizer05: you need a crowbar to get that battery out ...
<roh>
less insertion force means bad contact.
<DocScrutinizer05>
usually not
<DocScrutinizer05>
(whale > dino)
<wpwrak>
DocScrutinizer05: i've experimented quite extensively with these holders. just trust me ;-)
<roh>
there is a reason for the one there. it doesnt fall out. so one calculates the minimum at rated current, and then ramps that up to whatever is needed to hold the weight of the battery on given spec gfoces.
<DocScrutinizer05>
I know those holders. I always thought it quite assuring when battery sits tight
<wpwrak>
roh: naw, they need all that pressure not for electrical contact but because they don't have a case
<wpwrak>
there's some nice strong plastic around it ...
<wpwrak>
... unless it figures out how to quantum-tunnel though it, it really won't go anywhere else
<wpwrak>
roh: the SMT ones also don't stick too well to the PCB (especially considering the enormous force). better use a through-hole version.
<whitequark>
wpwrak: I (still) don't really get your choice of OLED. don't LCDs eat hundreds of uAs instead of tens of mAs?
<roh>
wpwrak: ive heard about that.. but never had an issue on proper fr4 boards
<roh>
i guess the homemade ones delaminate more easily
<wpwrak>
almost twice as fat as the cr2032 ;-)
<wpwrak>
whitequark: it's the backlight that kills you ...
<whitequark>
OLED probably eats less than LCD with backlight, but do you really need that?
<whitequark>
and if you do: can't you add a button which turns on backlight? like they do on watches
<DocScrutinizer05>
>>Awesome, it looks like a cartoon cat!<< LOL
<wpwrak>
non-backlit lcds are often a pain to read. specially if you have something more complex than huge 7 segment digits
<whitequark>
wpwrak: dunno, I find non-backlit monochrome LCDs pretty readable. I may be biased though
<whitequark>
dot matrix
<wpwrak>
another issue is that panel sizes go up when you move to this kind of display
<wpwrak>
that is, for off the shelf parts
<whitequark>
w/h?
<wpwrak>
and everyone seems to integrate a backlight
<wpwrak>
mainly thickness, but also junk around the active area
<DocScrutinizer05>
dang, I moved the N900 to the other room again, so no photo of my homematic CCU LCD display
<wpwrak>
of course, LCD can be very think. but it seems that these are custom designs again.
* whitequark
looks at a nokia3310 display lying around
<wpwrak>
err, very THIN
<DocScrutinizer05>
OLED start to get exciting when I can *roll* then out of the device, to get a 10" screen
rz2k has quit []
<wpwrak>
get a laser beamer ;-)
<DocScrutinizer05>
meh
<DocScrutinizer05>
TI blaze already *has*beamer integrated
<DocScrutinizer05>
doesn't sound too good for standard usecase though
<DocScrutinizer05>
it's more about idiots drooling over a 15" video projection at the wall, in an absolutely dark room 8maybe the videos that would be siutable for such usecase line up nicely with dark rooms)
<whitequark>
this one is 1.8mm thick
<whitequark>
dunno if you can source them
<DocScrutinizer05>
whitequark: and probably even has backlight
<wpwrak>
backlight = power-hungry
<whitequark>
DocScrutinizer05: nope, backlight was on the pcb
<DocScrutinizer05>
ohwell
<whitequark>
LEDs mounted so they emit light in parallel with the PCB
<wpwrak>
with oled, i can control the power drain by keeping as many pixels as possible dark
<wpwrak>
with lcd it's all or nothing
<whitequark>
wpwrak: but really, how much of the time will you *need* (back)light?
<whitequark>
you have a freakin' big light right in front of you (computer display) at all times, for that matter
<whitequark>
or phone display, though that works somewhat worse
<wpwrak>
depends on the display type. some need it all the time. some can work with ambient light, but have poor contrast
<larsc>
wpwrak: my psychic skills needs some work, it took some time to wake to spirit ;)
<wpwrak>
larsc: it still worked impressively quickly :)
garlp has joined #qi-hardware
<garlp>
Hi. My codepage is right?
arossdotme has joined #qi-hardware
<garlp>
halloooo
<wpwrak>
hmm, where's a klingon example in proper unicode when you need one to copy & paste ?
<wpwrak>
(anelok) meanwhile, the key components (transceiver, MCU, memcard, usb, a few caps) are soldered. should be able to try SWD soon.
<wpwrak>
kinda curious whether the mcu will be willing to talk ...
<wpwrak>
mcu was relatively easy to solder. positioning is hard, as usual with QFN in a DIY process. transceicer had a mystery short between ground and clock out. memcard may have some footprint issues - the contacts don't seem to be quite where they should be. needs checking.
<wpwrak>
usb looks intimidating (the shell covers the signals almost completely) but was surprisingly easy to solder.
<wpwrak>
there are probably some very large ones with roughly that size :)
<larsc>
wpwrak: yea, I was thinking about those back from a few years ago
<larsc>
I find it amazing how fast you were able to put this together
<garlp>
hi from Russia
<larsc>
hello
<garlp>
larsc: my codepage is right? ok
<larsc>
at least the ascii part of it
<wpwrak>
it's about half the size of a PCMCIA card
<wpwrak>
couldn't find any of my ancient (and huge) usb memory sticks. i remember one from sony that was particularly oversized.
<wpwrak>
larsc: it's till too early to know whether i actually got it right ;)
<larsc>
even for an almost working prototype it was still pretty fast
dos11 has joined #qi-hardware
dos11 is now known as dos1`
dos1` is now known as dos1
viric has quit [Ping timeout: 240 seconds]
<DocScrutinizer05>
wpwrak: C20 and C22 look *very* strange
<DocScrutinizer05>
if those are correct, I'd not really know why POWERED at B1:2 and why C23. I'd rempve POWERED then and make C23 0R
<DocScrutinizer05>
or that at86rf232 is a really strange chip when it needs that circuit
viric has joined #qi-hardware
rz2k has quit []
<wpwrak>
well, they say it needs those DC blockers
<wpwrak>
"POWERED" just tells kicad that this is a power input. otherwise, i'll get an ERC warning
<wpwrak>
(power input for declaring the middle tap as GND)
<wpwrak>
maybe i should make it passive. it looks inded a bit odd the way it is now.
<wpwrak>
the baluns have rather conflicting descriptions of what should go there. some say "just ground it". that's where the "power in" comes from
<DocScrutinizer05>
R9 what the heck?
<wpwrak>
everybody loves R9 ;-)
<wpwrak>
it's to supply the RTC. the basic ideas is to limit battery current such that the device can be in deep sleep (with RTC running) but can't do anything else
<wpwrak>
especially that it can't turn on RF
<wpwrak>
well, it could try to. but then the power supply would collapse.
<wpwrak>
hmm, the bad think about these tiny components is that, when you divert your attention for a second, you have a hard time finding them again ...
<DocScrutinizer05>
when you want to disable RF, switch off AT86Rf232
<DocScrutinizer05>
R9 makes the whole circuit behave undefined
arossdotme has quit [Ping timeout: 240 seconds]
<wpwrak>
the MCU is supposed to catch power dropping and shut things down
<DocScrutinizer05>
that's not a stable design
<wpwrak>
and the purpose of this is to protect against a rogue MCU
<wpwrak>
yeah, i guess it may bounce around in power-on-reset
<DocScrutinizer05>
there's no way for the circuit to detect state of the switch, except try to draw huge amount of current, in which case VDD drops and probably RTC doesn't work either. While it does NOT reliably stop RF since you got buffer Cs
<wpwrak>
my idea is to set a high brown-out level and trigger on that. this code would shut down things very quickly, before reaching the low brown-out level
<wpwrak>
the caps are way too small to feed RF for anything. so they actually help, buying us a little more time for the cleanup.
<wpwrak>
the main cap there is C15 anyway
<larsc>
can't you connect that switch to reset, for both the mcu and rf?
<DocScrutinizer05>
yeah
<DocScrutinizer05>
this is insane design
<DocScrutinizer05>
why would the CPU work with "brownout" when it gone rogue regarding any more sane design?
<DocScrutinizer05>
and duh, this MCU doesn't need a xtal for rtc??
<DocScrutinizer05>
and no separate power VDD pin for rtc?
<wpwrak>
it has no separate power pin for RTC
<wpwrak>
(unfortunately)
<wpwrak>
hence that hack
<DocScrutinizer05>
then see what larsc said
<wpwrak>
(rogue) i don't expect it to work with brownout if it goes mad. all bets are off then. but i want to be sure that the system can't do anything "interesting" when the switch is in the off position
FrankBlues has joined #qi-hardware
<wpwrak>
holding everything in reset may be an option. need to see about that.
<DocScrutinizer05>
then switch off the RF chip
<wpwrak>
alas, the MCU does not define a reset state for the GPIOs. so they can be anything. i'm sure it makes perfect sense in some parallel universe ...
<wpwrak>
properly switching off the RF chip would still require the MCU to cooperate
<wpwrak>
but holding it in reset may be an option. need to check the current.
<DocScrutinizer05>
kill the clock -> no more RF
<DocScrutinizer05>
just a brainstorming idea, when reset doesn't work
<wpwrak>
killing the clock means messing with the crystal
<DocScrutinizer05>
yeah, sth like that
<wpwrak>
well, i guess one could forcible ground it but ...
<wpwrak>
but it does sound a bit like asking for trouble
<DocScrutinizer05>
probbaly
<DocScrutinizer05>
switching off VSYS not feasible?
<DocScrutinizer05>
maybe only for one of EVDD DEVDD
<wpwrak>
again, power through GPIOs
<DocScrutinizer05>
I guess one is logic, the other analog?
<wpwrak>
yes
<DocScrutinizer05>
doesn't it define what happens when analog is unpowered?
<wpwrak>
of course not :)
<DocScrutinizer05>
:-S
<DocScrutinizer05>
I'd go for pulling RF_nRST to GND. Can get detected by MCU by using PTC2 as input
<DocScrutinizer05>
If you want or need that, you also can connect PTC2 to MCU nRESET via a R-C to give a pulse to nRESET when the switch gets closed
<DocScrutinizer05>
ooops, no :-P
<wpwrak>
hmm yes, that could be a possibility (forced reset)
<wpwrak>
i think the PTC bank is interrupt-capable, so detection shouldn't be a big deal
<DocScrutinizer05>
I anyway *strongly* recommend _not_ to use that R9 "solution". Might work, when you're extremely lucky, but yuo never can completely evaluate and verify the circuit behaviour
<DocScrutinizer05>
s/yuo/you/
<qi-bot>
DocScrutinizer05 meant: "I anyway *strongly* recommend _not_ to use that R9 "solution". Might work, when you're extremely lucky, but you never can completely evaluate and verify the circuit behaviour"
<wpwrak>
and it would be for "cleanup" anyway (set GPIOs, stop expecting RF to work, etc.)
<wpwrak>
yeah, it's a bit chancy
<wpwrak>
need to see how much RF draws in reset. that's of course undocumented.
<wpwrak>
SLP_TR (sleep mode) may or may not have an effect there, too
<wpwrak>
in-circuit programmer is unhappy with what i've done :-( let's find out why ...
FrankBlues has quit [Remote host closed the connection]
<wpwrak>
btw, there's another "chancy" mode: when removing the battery, the MCU needs to catch the imminent complete loss of power and bring down things, so that C15 can keep the RTC alive during the battery change
<wpwrak>
will be fun to make this work :)
rozzin has left #qi-hardware [#qi-hardware]
<DocScrutinizer05>
forget it
<DocScrutinizer05>
lock the battery lid with the slide switch SW2
<wpwrak>
naw, switches are too much of a pain
<wpwrak>
they're huge, expensive, and never quite fit
<DocScrutinizer05>
if you can't do that, then get two Vbat+ contacts on the PCB, the detector one opening earlier than the main one
<wpwrak>
interesting idea
<DocScrutinizer05>
or a Reed or Hall or IR-proxy switch on your case, "intrusion detector"
<wpwrak>
satellite surveillance ;-)
<DocScrutinizer05>
for that your refusal to make battery slot-in actually is beneficial
* wpwrak
feels victorious :)
<DocScrutinizer05>
adding a tiny magnet to the removable "lid" and a Reed switch on PCB next to it is dead simple
<DocScrutinizer05>
you still didn't explain how that magic MCU keeps realtime without an XTAL
<cde>
`d
<wpwrak>
it has a reasonably accurate RC
<larsc>
DocScrutinizer05: built-in xtal
<DocScrutinizer05>
nifty
<wpwrak>
and we can calibrate it against the very precise xtal
<DocScrutinizer05>
`d ?
<wpwrak>
the rtc is for things like security tokens. so it doesn't have to be extremely accurate.
<wpwrak>
the code they generate normally depends on time (and usually on the number of activations)
<wpwrak>
the little critters that generate a code when you turn them on. then you type it into some authentication system. for two-factor authentication.
hellekin has quit [Ping timeout: 245 seconds]
<cde>
DocScrutinizer05: sorry, typing mistake
<wpwrak>
weird. if i connect the board to the programmer, the programmer doesn't even enumerate on usb
<wpwrak>
all the signals look correct, though
<larsc>
does the programmer power the device?
<DocScrutinizer05>
VBUS
<wpwrak>
yes, power looks normal
<DocScrutinizer05>
err wait, what exactly are you saying?
<DocScrutinizer05>
is the programmer connected to anelok via USB?
<wpwrak>
no, via GND, VDD, and SWD
<DocScrutinizer05>
aah, and what does it do? is it a own system or just some sort of level shifter to USB?
<apelete>
larsc: seems like the driver is not being loaded, and I don't know why it's printing "musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)"
<apelete>
in platform data I set it to peripheral only....
<apelete>
cde: not funny :D
<wpwrak>
in the movies, when someone falls to their death, they usually shout "aaaaa...". maybe that kernel found the choice of last words of these people inspiring.
<cde>
in kernel land, no one will hear your scream
<roh>
hrhrhr
<larsc>
apelete: hm, i can't even find the code that prints that message
<larsc>
ah, it was removed
<larsc>
it prints that message when the module is loaded
<wpwrak>
someone's been hiding evidence
<apelete>
larsc: so the module is being loaded ? it doesn't pring any of the printk I left in the glue layer...
porchao has joined #qi-hardware
<larsc>
those will probably run only when the device is created
<larsc>
or maybe the glue code is build as a module
<larsc>
but the core code is built-in
porchaso0 has quit [Ping timeout: 248 seconds]
<DocScrutinizer05>
0xaa is a very common pattern for unititialized RAM
<DocScrutinizer05>
0x55 the other one, besides of course 0xff and 0x00
<larsc>
both seems to be built-in
<DocScrutinizer05>
basically all memtesters use 0xaa and 0x55 for test patterns
<larsc>
I think the kernel also uses it to poison memory
<wpwrak>
hmm. disconnecting RESET makes the programmer enumerate. SWD still fails later on, though.
<wpwrak>
.. because there is no reset. yes, that makes sense :)
<wpwrak>
very strange
<wpwrak>
resistance of RESET is normal, too. some 13 MOhm to GND (if driven high), about 50 kOhm to VDD (if driven low)
<apelete>
mth larsc: any idea on how I should proceed to solve this ?
<apelete>
I tried to step into the musb glue layer code with gdb but it didn't break
<apelete>
don't know why
<apelete>
I mean, I can see the kernel booting inside gdb, but putting a breakpoint in the probe() function does not break the kernel
<larsc>
comment out parts until it is working again
<larsc>
this looks like a real bad memory corruption
rz2k has joined #qi-hardware
<wpwrak>
*hmm* could it be ... freescale being assholes ? there's a thread suggesting that the "open"sda subsystem simply doesn't enumerate if the chip isn't the one on the board. https://community.freescale.com/thread/303031
<apelete>
larsc: ok thanks, will try that
<wpwrak>
what's odd with this: 1) if i break reset such that it can't even talk to any chip, it does enumerate. 2) the chip is not identical but quite similar. (same core, same memory, different package)
<wpwrak>
IDCODE should be the same for all M0+. hmm.
<larsc>
so you think the firmware finds the chip and then shuts itself down?
<wpwrak>
i think i found it :) there are two slightly different debug connectors on the board, J6 and J8. i attached to the wrong one. let's try the other one.
porchao has quit [Quit: Leaving...]
<wpwrak>
yeah ! talks :)
kilae has quit [Quit: ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]]
<larsc>
now it just need to walk
<wpwrak>
let's try something innovative and completely unexpected ... blink a led :)
viric has quit [Ping timeout: 240 seconds]
pcercuei has quit [Quit: brb]
pcercuei has joined #qi-hardware
viric has joined #qi-hardware
porchao has joined #qi-hardware
<wpwrak>
kewl. the led blinks on the first try. that was too easy :)
<eintopf>
:D
wej has quit [Ping timeout: 245 seconds]
<DocScrutinizer05>
lol
<DocScrutinizer05>
on a sidenote, I felt a little puzzled about the LED's series R
<DocScrutinizer05>
a tad low for a lowpower device
<DocScrutinizer05>
you usually use high-efficiency LEDs in this case, which don't need >1mA to properly shine
<DocScrutinizer05>
I didn't check the math, but 120R sounds a tad low, thus current probably higher than I'd consider OK
<DocScrutinizer05>
sounds more like 10..20mA than 1..2mA
<wpwrak>
nice. MCU comes up, SWD works, LED works. also tested that the transceiver has a clock. good enough for today. there's still a lot more to test. the boost converter may still cause a few surprises. that's the last completely new subsystem remaining. well, and USB will be its usual messy self.
<DocScrutinizer05>
I still wonder how exactly this thing is menat to get used
<DocScrutinizer05>
the description on git doesn't sell it to me
<DocScrutinizer05>
do you plug this in to PC USB and it emulates a (2nd) kbd?
<DocScrutinizer05>
and what for is the RF?
<DocScrutinizer05>
btw wtf SWD?
hellekin has joined #qi-hardware
<wpwrak>
you don't like SWD ?
<wpwrak>
the basic usage concept is that it stores PWs. then you have a number of ways to use them: 1) display and let the user do something with them. 2) send over USB (as HID). 3) send over RF (as HID). 4) use for challenge-response (with USB/RF). etc.
<wpwrak>
RF is just to avoid the cable.
<whitequark>
using RF for a password safe... huh
<wpwrak>
whitequark: well, encrypted of course
<whitequark>
for a typical user would make no difference, I guess
<whitequark>
wpwrak: still much more attack surface
<wpwrak>
true. you can choose to not use RF :)
<whitequark>
but, if someone wants your credentials that much, I guess there are worse problems
<DocScrutinizer05>
ugh, couldn't post THAT URL here, but seems SMD are less common on 2mA, but I found a blue and a white one @ 5mA IF
<DocScrutinizer05>
and now I finally read backscroll ;-P and notice you already found all this as well
<DocScrutinizer05>
(catch) I don't know exactly. something with different dotation(?), transparent chips, reflectors, maybe even different material all together (like GaAsP)