<wpwrak> drums, please !
<kristianpaul> linux.. :-), i have a osgps running for mips, well why not linux
<kristianpaul> uclinux**
<aw_> rc3: just captured R157, factory didn't 2 pcs while I measured already 17pcs. ;-) so this makes me remembered that my first 2 / 10 pcs got d2/d3 dimly lit after reflashed. ;-) I'll go back to check them. :)
<aw_> so far now just measured impedances after 20pcs, I didn't see "short" conditions though, this also makes me felt that I must make sure to get boards fully dried since I put them overnight after cleaned.
<roh> i have 225buttons of 240 done. need to wait for them to harden finally. also need to make some new ones (lost 2 pieces somewhere and mis-glued some)
<roh> but i still have material. will get the rest done later (after sleeping)
<aw_> roh, sleep firstly then brain get clear. My brains always get stock when work late. ;-)
<aw_> roh, so 3 * 80pcs = 240pcs, no more spares?
<kristianpaul> +1 to spares, i also need some ;^)
<roh> yes. i can do spares. (need to laser replacements from the leftovers anyways) .. how many should i make? like 5 more kits of 3 buttons?
<larsc> I don't think it's correct either, but it works. And there is currently a lot of restruturing done in the upstream memblock with the final goal to get rid of bootmem, so I think it's best to wait until that is done, before cleaning up our code
<larsc> mwalle: ^
<roh> kristianpaul: do you get a shipment from taiwan? i can put some without the button cap glued on in there for you as well.
<roh> or you could make them yourself.. its simply a 0.5mm thick disc with 7.9mm diameter as spacer and a 1mm thick disc of 12mm diameter behind it. (so its cap, small and thin disc, big and thicker disc from front to pcb)
<roh> beware. its evil.
<aw_> roh, i didn't send any spares for kristianpaul . ;-)
<aw_> wolfspraul, do you think that how many spares of roh's sets of 3 buttons we need? since surely we haven't known how many boards in the end they will have?
<wolfspraul> don't understand
<wolfspraul> what?
<wolfspraul> :-)
<wolfspraul> spares, roh, kristianpaul, Adam, Taiwan?
<aw_> Taiwan here for Adam. ;-)
<wolfspraul> I ordered 80 full sets of cases, to be shipped to Adam in Taipei. That's step 1 :-) Beyond that I don't know anything.
<wolfspraul> roh: how are things going?
<aw_> we mounted 90 pcs for rc3 boards, other accessories stocks here http://en.qi-hardware.com/wiki/Milkymist_One_accessories#available_stocks
<roh> wolfspraul: got 75*3 buttons done (final qc not yet, but glued)
<wolfspraul> almost! cool! 5 to go :-)
<roh> found that i am missing 2 buttons, rest follows after sleeping etc
<wolfspraul> good, get a rest. Adam will have interesting test results later today...
<roh> will laser some more as spares from the leftovers i have. so i will simply do some more so you have spares if some dont want to fit
<wolfspraul> nice
<roh> i hope i can complete the rest later/tomorrow (the glued parts should rest 24hours ive read) and if everything goes as planned i should be able to ship the stuff.
<roh> question still is: which carrier ;)
<wpwrak> avian ? :)
<wolfspraul> roh: what about the logo?
<roh> ah. yes . that needs to be done too. *nih*
<wolfspraul> for shipping, let's see
<wolfspraul> I guess our options are fedex, dhl/deutsche post, hand-courier by zecke :-)
<wolfspraul> let's finish the stuff first
<wolfspraul> actually zecke could take them and we save some money, but I'm a little worried about the VAT return/export thing. He would have to walk to some customs counter at the airport and have a few documents stamped or so. Maybe he even gets the VAT cash back there? I never did this process...
<wolfspraul> otherwise we just pick deutsche post or fedex or so. no worries.
<wolfspraul> last time it worked pretty well
<roh> ok
<aw> still 35pcs need to be measured impedances. phew~
<GitHub111> [linux-milkymist] larsclausen pushed 1 new commit to master: https://github.com/milkymist/linux-milkymist/commit/ae1dcb3a00d95b87a092689f1b29a05bbfb44be2
<GitHub111> [linux-milkymist/master] milkymist-gpio: Fix copy&paste error - Lars-Peter Clausen
<aw> 8 / 90 has short conditions: haven't investigated yet. next steps to voltage/current test @ 0.7A limited from lab power supply
<wolfspraul> aw: interesting
<wolfspraul> for example for 0x7B, you have an 'X' but then you corrected R157, right? did it then pass, or still fail?
<aw> wolfspraul, let's move forward firstly, finally PASS. when I marked 'X' means it happened then.
<aw> wolfspraul, 1. R157-4.7K ohm, replaced 10K done. ;-)
<wolfspraul> aw: but the test still fail after replacing R157?
<wolfspraul> I noticed 0x7B and 0x87 are both like this
<aw> wolfspraul, NO, Pass after replaced a corrected R157-10K done.
<aw> 0x7B & 0x87 are done. ;-) sorry that I should have noted well. :)
<aw> notes are revised.
<wolfspraul> ok
<wolfspraul> aw: let's see how it continues :-)
<GitHub117> [extras-m1] yizhangsh pushed 1 new commit to master: https://github.com/milkymist/extras-m1/commit/96946ab8a0402630ba9862c2190af5ea69dfc969
<GitHub117> [extras-m1/master] removed redundant file - Yi Zhang
<GitHub167> [milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/72a4243c9d3ddf5396a2d345ebbbfcf5f840fe99
<GitHub167> [milkymist/master] demo: cleanup output - Sebastien Bourdeauducq
<aw> voltage/current results updated but not finished all, check it out.
<lekernel> what's wrong with 31 and 3A reflash?
<lekernel> that's a new problem
<lekernel> and 55
<wolfspraul> you mean 0x32 and 0x3A? no they are all old
<wolfspraul> actually it starts to look much better now, let's see how things continue
<wolfspraul> maybe it will be a pretty good run in the end, after all :-)
<wolfspraul> certainly the results that came in today, so far, were good
<kristianpaul> roh: sue
<kristianpaul> sure*
<kristianpaul> i mean with +1 that having spares is good,
<kristianpaul> meant*
<kristianpaul> wolfspraul: i just tought if roh ship you extra spare parts, adam can ship me later sme screws buttons.. etc.. of course by the cheapest mail i pay the order
<kristianpaul> wolfspraul: if you agree of course
<wolfspraul> lekernel: I'm trying to figure out what exactly makes up the anti-aliasing circuit we can remove when switching to ADV7181C. Is it L14/15/16 - that part?
<kristianpaul> i dont  need buttons btw :)
<wolfspraul> kristianpaul: why should I not agree :-) roh can put some into a letter too if it's easy, or Adam can, sure. Just need some spares first somewhere...
<kristianpaul> roh will be nice
<kristianpaul> letter*
<kristianpaul> i just need screews and the rubber thing in the botton, too keep air flow okay
<wpwrak> kristianpaul: can't you find all that in the next DIY market/ferreteria ? :)
<kristianpaul> i'm worried about margins
<wpwrak> kristianpaul: certainly the "rubber thing" if you mean "feet"
<kristianpaul> yes
<wolfspraul> wpwrak: did I identify the anti-alias circuit correctly? I'm having some fun reading schematics but I don't want to be responsible for ripping out life-supporting organs :-)
<wolfspraul> I think it's L14/15/16? but can the varistors go as well? or was that the surge protection we added? and how about C202-C207 - can they go?
<wolfspraul> :-)
<wpwrak> wolfspraul: dunno. this is the first time i even hear of an anti-alias circuit. so far, i think that was some software, maybe hardware ;-)
<wolfspraul> I was just having fun playing EE
<wolfspraul> I think I am ready soon, he he
<wolfspraul> incompetence galore, where is my soldering iron?
<wolfspraul> Adam's test results so far look good, gives me a second wind
<wpwrak> ah .. aliasing = ghosting maybe ?
<wpwrak> i.e., reflection on the video signal line ?
<wpwrak> what chip was the codec before ?
<wolfspraul> it's really called antialiasing circuit, see p97 http://www.analog.com/static/imported-files/data_sheets/ADV7181B.pdf
<wolfspraul> that is not needed any longer with the ADV7181C (it has been integrated, I guess)
<wolfspraul> in the m1 schematics, on p12, I think it must be something connected to AIN4-6
<wolfspraul> so I figure - rip out L14-16, and maybe it's the right thing?
<wolfspraul> that's the block that is in the way, he he
<wpwrak> hmm. fig. 44 is off. no input, no output ? :)
<wolfspraul> look on the next page
<wpwrak> at least it connects to two power rails ;)
<wolfspraul> they say this should be plugged into any incoming line
<wpwrak> yes, fig. 45 shows the black box as if it had inputs and outputs, then points to fig. 44. that doesn't really help ;-)
<wpwrak> you're probably supposed to connect between C93 and R38, and between L10/C102 and R63
<wpwrak> now, what makes you think you can remove things ? it looks as if you should _add_ quite a lot of filter circuit ?
<wpwrak> (alias) ah, now i understand the terminology. it's now impedance matching but HF components (from wherever) riding on the input
<wpwrak> hmm. the whole circuit looks a little fishy. a bead can also remove HF, that's true. what bead are you using there ?
<wpwrak> the DC blocking caps seem under-dimensioned. fig. 44 has them 1000 times as large
<wolfspraul> just confirmed - we added the varistors V5-V7 as some sort of protection in rc3, so that's definitely not part of it
<wpwrak> varistors are just a protection, plus some parasitic capacitance
<wolfspraul> so it must be L14-16, and maybe C202-C207. my guess.
<wpwrak> so is there a specific problem with the video at the moment ? or are you just poking around ?
<GitHub188> [uclibc-lm32] larsclausen pushed 2 new commits to master: https://github.com/milkymist/uclibc-lm32/compare/71624d5...fd35373
<GitHub188> [uclibc-lm32/master] Fix dup3 - Lars-Peter Clausen
<GitHub188> [uclibc-lm32/master] lm32: Sync kernel_types.h - Lars-Peter Clausen
<wolfspraul> no problem. we are switching to ADV7181C which doesn't need the antialiasing filter anymore. I try to figure out what exactly needs to be removed.
<wolfspraul> that's for rc4
<wpwrak> aaah !
<wolfspraul> if I'm even looking at the right place in the schematics, it must be L14-L16. but I may be totally wrong...
<wpwrak> yes, the circuit looks a LOT more like what ADV7181C wants ;-)
<wpwrak> and L14-16 do indeed seem redundant. not sure if they actually hurt. they could even prevent some RF creepage. C202 through C207 also seem unnecessary. but maybe make them NC, just in case.
<wpwrak> wouldn
<wolfspraul> B works well with what we have today
<wpwrak> 't it be good to connect AIN1 through AIN3 to test points ? in case someone wants try and add something new
<wpwrak> the B data sheet suggests that it depends on the nastiness of the source. and manifests itself in noise. maybe you've only tried "nice" sources. or sources that are already noisy. or you just didn't look hard enough for the noise ;-)
<wpwrak> have you tried to connect a PC with a clean VGA signal and looked at what the M1 makes of that signal ?
<wolfspraul> sure, all possible. no test point proliferation... I am just trying to understand what to remove exactly :-)
<wpwrak> (tp) okay. just struck me as one of those places where a TP could be nice to have. well, it's a component with leads, so you can always improvise later. not like the USB host in the ben ;-)
<wpwrak> but yes, it looks as if the beads could probably go. at least half of the 120 pF caps, too. (beads plus caps form a somewhat odd Pi filter. do you know if that filter was put there specifically for the aliasing problem ?
<lekernel> antialiasing circuits are low-pass filters put before an ADC to block frequencies higher than half the sample rate (as they would cause aliasing, hence the name)
<lekernel> there are also optical antialiasing materials to put before CCD sensors, etc.
<lekernel> in our case it's the "pi" circuit made of the 120pF caps and ferrite beads
<lekernel> there's one per channel
<wpwrak> lekernel: so far. so good. now, if the "pi" intended as a replacement for the active filter suggested for the ADV7181B ?
<lekernel> yes, I copied this from an altera board
<wpwrak> aah, i see
<lekernel> that was fast to make, and I like fast things.
<wpwrak> so wolfgang would be right and the ADV7181C shouldn't need that pi, agreed ?
<wpwrak> (fast) ;-)
<lekernel> yes
<lekernel> just DNP the caps and use a 0 ohm resistor instead of the bead
<wpwrak> (fast) makes me wonder what kind of vehicle you drive :) or will drive once M1 becomes a stunning success :)
<lekernel> I don't think we should change the PCB layout
<wpwrak> (DNP/0R) yes, that sounds like the easiest approach
<lekernel> so it stays compatible with B
<wpwrak> also gives you some flexibility if some obscure issues pop up
<wolfspraul> pcb layout has to be changed for the logic gates, no?
<wolfspraul> so we can fix L19 and the antialiasing filter removal in the pcb as well, unless it's just not wanted...
<wolfspraul> so that was correct - L14-L16 and C202-C207 can go?
<wolfspraul> either DNP/0R or remove altogether...
<lekernel> let's test the logic gates thoroughly first
<lekernel> they work flawlessly in theory, but the diodes were supposed to as well ...
<lekernel> but yes, the PCB layout will need a few changes in all cases
<wolfspraul> lekernel: if the PCB layout changes anyway, do you still want to keep L14-16/C202-C207 or it's ok to remove them entirely?
<lekernel> it should be ok to remove them entirely
<wolfspraul> thx
<lekernel> but it breaks compatibility with B
<wolfspraul> someone unsoldering the C to revert to B? :-)
<wolfspraul> btw our sourcing contact in Shenzhen did indeed confirm that the B is harder to source now, C is cheaper too
<wolfspraul> C is 1.50 USD cheaper
<wolfspraul> unless we buy B in larger quantity, then it might be about the same as C :-)
<wolfspraul> sourcing magic
<lekernel> what is that "unicore32" architecture?
<lekernel> seems to be some research processor by a Chinese lab
<lekernel> "Based on the Unity-863 SoC, MPRC has built a complete SoC design platform. MPRC is now working at several SoC design projects with the cooperation of several organizations using this platform." ...which ones??
<lekernel> google gives only qemu and linux patches
<aw> rc3 voltage/current measurements before reflash done: total current is 0.53A +/- 0.01A, 0x62 gets 0.6A while my lab power supply sets @ 0.7A.
<aw> next step to reflash tomorrow
<lekernel> of course, they get the usual autocrap problems: http://fgsink.blog.163.com/blog/static/1671699702011624111911824/
<lekernel> aw, some part on 0x62 probably gets hot
<aw> lekernel, ha~i put my fingers to feel, didn't find. ;-)
<aw> let's temporarily leave 0x62 now, let's go for reflash and use test tool to test others then back to investigate failed boards. :-)
<lekernel> btw you are still using 'verify' during flashing?
<lekernel> this is painfully slow. I though Xiangfu would have integrated CRC checking into the test program ...
<aw> hi no, only i enable 'verify' while I re-test once I wanted to check flash chip. yes super painfully slow though.
<aw> guessed xiangfu haven't integrated CRC checking into it, but good reminder, I email him.
<aw> night all. cu
<larsc> lekernel: hm, i accidentally pushed made HEAD point to the lm32 branch instead of master in openwrt-milkymist branch, and apparently you can only change it if you have admin rights for the repo
<GitHub129> [extras-m1] yizhangsh pushed 1 new commit to master: https://github.com/milkymist/extras-m1/commit/10f3bd0dfe2a63d81129699b469de29f3c3001b7
<GitHub129> [extras-m1/master] changed fonts in use - Yi Zhang
<lekernel> larsc, better now?
<lekernel> does this openwrt port work btw?
<larsc> yes
<larsc> clone, select milkymist, run make and you get a bootable kernel+rootfs
<lekernel> yes it's better, or yes it works? :)
<larsc> both ;)
<lekernel> with the master or lm32 branch?
<lekernel> cool
<lekernel> let me try :)
<lekernel> ah, and it's got ipv6 ;)
<larsc> killer feature ;)
<larsc> hm, apparently to much of a killer feature
<lekernel> yes
<GitHub85> [extras-m1] yizhangsh pushed 1 new commit to master: https://github.com/milkymist/extras-m1/commit/53f2017f1bd858782f258d7e7e04b4a17dcad32a
<GitHub85> [extras-m1/master] removed unused font - Yi Zhang
<larsc> so the bug is libgmpxx not linking against libstdc++?
<lekernel> apparently. the proposed fix worked for me.
<lekernel> still compiling now ...
<mwalle> lekernel: larsc: is networking working?
<mwalle> the linux port still has the old minimac1 driver
<mwalle> looking at it atm
<mwalle> bbl
<lekernel> Cloning into elf2flt-08d80172231853b2d2a7bf03d94a9d7115c3d348...
<lekernel> fatal: dumb http transport does not support --depth
<larsc> git revert 0fbc1903f8d516e03af319419ae90ea1811dbe55
<lekernel> yup, done. i was just reporting the issue.
<lekernel> now the kernel won't compile:     LD      usr/built-in.o
<lekernel> make[7]: *** No rule to make target `arch/lm32/kernel/gpio.o', needed by `arch/lm32/kernel/built-in.o'.  Stop.
<larsc> hm...
<larsc> blames mwalle ;)
<larsc> i guess it built here because i already had gpio.o
<lekernel> this one is a bit more troublesome *g*
<lekernel> i'm editing out gpio.o from arch/lm32/kernel/Makefile
<lekernel> and pray it will link
<larsc> should work gpio.c was moved to platforms/milkymist
<GitHub183> [linux-milkymist] larsclausen pushed 1 new commit to master: https://github.com/milkymist/linux-milkymist/commit/2b01591062b9d4ee4bb4c05485f6c8f7b9e73e7e
<GitHub183> [linux-milkymist/master] lm32: Don't try to build kernel/gpio.o - Lars-Peter Clausen
<lekernel> so we can play with the LEDs from linux now? :)
<larsc> yes
<larsc> even via the leds sysfs interface
<GitHub189> [linux-milkymist] larsclausen pushed 1 new commit to master: https://github.com/milkymist/linux-milkymist/commit/f37bef13afa096897bb49f124a94a0ee9dbec08e
<GitHub189> [linux-milkymist/master] lm32: milkymist_one.dts: Set bootargs - Lars-Peter Clausen
<larsc> you'll need the last commit as well, otherwise it won't mount the rootfs
<lekernel> mh, what is simpleImage.milkymist_one ?
<lekernel> I just boot that? kernel+initrd combo?
<lekernel> apparently it's just kernel ...
<larsc> thats just the kernel
<lekernel> for some reason it seems it did not build a ramdisk image
<lekernel> even though it's selected in menuconfig
<lekernel> ls bin/lm32/
<lekernel> md5sums  openwrt-lm32-rootfs.tar.gz  packages  simpleImage.milkymist_one
<larsc> hm
<kristianpaul> larsc: (bootable kernel+rootfs) great !!
<larsc> lekernel: just select ext4 under target images
<larsc> and no ramdisk
<lekernel> there is no such option
<lekernel> ah, I have to deselect ramdisk before ...
<lekernel> Kernel panic - not syncing: No init found.  Try passing init= option to kernel. See Linux Documentation/init.txt for guidance.
<lekernel> with: Kernel command line: init=/sbin/init above
<lekernel> wtf
<larsc> hm
<larsc> rootfs is mounted?
<larsc> root=/dev/ram0 rootfstype=ext2
<lekernel> yes... maybe that's because of the \n at the end
<lekernel> of cmdline.txt
<lekernel> nope. still won't work.
<lekernel> RAMDISK: Loading 8192KiB [1 disk] into ram disk... done.
<lekernel> VFS: Mounted root (ext2 filesystem) readonly on device 1:0.
<lekernel> devtmpfs: mounted
<lekernel> Freeing unused kernel mem: 104k freed
<lekernel> Kernel panic - not syncing: No init found.  Try passing init= option to kernel. See Linux Documentation/init.txt for guidance.
<lekernel> checking initrd image atm
<lekernel> well... there is /sbin/init .. linked to the existing ../bin/busybox
<lekernel> but it refuses to work
<larsc> could you upload your rootfs?
<kristianpaul> larsc: this linux was tested in wich bitstream SoC version?
<GitHub98> [extras-m1] yizhangsh pushed 1 new commit to master: https://github.com/milkymist/extras-m1/commit/01b0d4e64262a7d3ac775a7bd2593381043ed133
<GitHub98> [extras-m1/master] 1) updated hackable-devices contact info; 2) rearranged page for A3 printing - Yi Zhang
<larsc> kristianpaul: i've tested it with a reduced bitstream
<kristianpaul> larsc: reduced from wich SoC version?
<lekernel> and kernel command line is init=/sbin/init root=/dev/ram0 rootfstype=ext2
<larsc> kristianpaul: i've disabled a few peripherals that are not supported by linux anyway
<kristianpaul> including ehernet core? :-)
<kristianpaul> anyway, i guess it should work..
<kristianpaul> i'll try as well
<larsc> hm, lekernel apparently something went wrong with elf2flat on your side
<larsc> lekernel: could you paste your openwrt .config?
<larsc> ah...
<larsc> busybox ignores the default CFLAGS or something like that...
<larsc> lekernel: CONFIG_BUSYBOX_CONFIG_EXTRA_CFLAGS="-Wl,-elf2flt"
<larsc> should make it work
<lekernel> yes, works :)
<lekernel> thanks :)
<lekernel> and congratz :)
<larsc> thanks
<lekernel> there's no framebuffer output (even though I have "milkymist_fb e0003000.vgafb: fb0: Milkymist frame buffer at 47200000, size 1536kB" in the log)
<mwalle> lekernel: on real hw?
<mwalle> btw simpleImage is kernel + dtb
<lekernel> yes
<mwalle> dtb linked into the kernel, normally, the dtb is an extra blob provided by the board
<mwalle> lekernel: mh i've only tested on qemu
<lekernel> maybe it needs a clearing of the reset bit
<lekernel> the bios sets it
<mwalle> /* take hardware out of reset */
<mwalle> iowrite32be(0, milkymistfb->ctrlbase + VGAFB_CTRL);
<mwalle> maybe the sync and scan registers are wrong
<mwalle> all ignored by qemu
<mwalle> lekernel: the control interface should work if hw is in reset, shouldnt it?
<lekernel> yes
<lekernel> in fact you should only modify the scan register values when it's in reset
<mwalle> lekernel: could you verify the settings?
<mwalle> btw does anybody know a way to access the physical memory through /dev/mem with standard unix tools?
<lekernel> with dd, maybe?
<mwalle> didnt work last time i tried it (on ppc) dunni, maybe i've done sth wrong
<mwalle> lekernel: could you upload your working initrd?
<lekernel> milkymist.org/openwrt20110727.tar.bz2
<mwalle> thx
<mwalle> typo?
<mwalle> 404
<lekernel> argh, yes
<lekernel> should be ok now
<mwalle> mh, my kernel wont work
<mwalle> lekernel: could you send me your kernel config? :)
<GitHub89> [linux-milkymist] mwalle pushed 1 new commit to master: https://github.com/milkymist/linux-milkymist/commit/e94ece6b49773e8cf000d6f8cd220695e0f82d62
<GitHub89> [linux-milkymist/master] lm32: enable flat support by default - Michael Walle
<lekernel> I used the default config built by openwrt ... which I deleted, sorry
<mwalle> right after init is started, there a message about uci_load (which i get in the good case too) but no prompt after that
<mwalle> larsc: do you have any idea?
<lekernel> I had that message too, but the prompt followefd
<lekernel> -f
<kristianpaul> there is an app in busybox that allow me to transfers files over tty?
<kristianpaul> at the same time i'm using it..
<mwalle> lekernel: mh vscan and vsync_{start,end} are different
<mwalle> kristianpaul: rx?
<kristianpaul> ah, cool thank one, thks mwalle :)
<kristianpaul> larsc: can you publish somwhere you're working bitstream with minimac old version?
<mwalle> larsc: did you test the (old) milkymistfb driver on real hw?
<lekernel> the old driver worked for me
<mwalle> mh
<mwalle> i'll flash my mm1 tomorrow :)
<mwalle> lekernel: i guess i have to look at the rc2 schematics for the ac97 rework?
<timg> Hey there I just got a MilkyMist one and the keyboard will not work from a Mac are there specific known working keyboards?
<wpwrak> timg: you may have to experiment a bit. as a general rule, the simpler the keyboard, the better. USB hub, built-in track pad, and similar things are to be avoided
<wpwrak> timg: they did a bit of research here: http://en.qi-hardware.com/wiki/Milkymist_One_accessories#keyboard
<timg> ok, I thought I may find that to be the case
<roh> mwalle: afaik the rework only was removing the codec and placing an new one
<roh> maybe one or 2 resistors needed changing. not sure anymore.
<wpwrak> roh: "only" :) if i remember correctly, it has been performed successfully only once so far
<timg> any chance anyone got like an apache server on the device to control OSC etc?
<roh> wpwrak: we did it here in the raumfahrtagentur, so it is, per definition basic kitchen-table engineering ;)
<roh> C255 47nF/0402, 3D high pass filter. C253 10uF/0805, C254 100nF/0402, CAP2 de-coupling capacitors U1.pin_44, SPDIF_ENABLE U1.pin_48, SPDIF OUT
<roh> thats what i can find about the codec rework. afaik it did just work after swapping. not sure if the cap changes are that important.
<timg> does MM1 come with OSC support? if not is it easy to add?
<roh> timg: it does
<timg> oh cool
<timg> now to start work on a new Android App :-)
<roh> timg: flickernoise uses https://github.com/milkymist/liboscparse
<timg> good info