<xiangfu>
my camera is kind of hot in those two days. maybe because now is summery?
<xiangfu>
~40 degree
<wolfspraul>
it's probably more than 40
<wolfspraul>
yes it gets hot
<wolfspraul>
we rely on the vendor to make a stable design, right now I have no reason to doubt their work. The camera uses passive cooling, meaning that the entire camera gets warm, and the air around it will dissipate the heat.
<wolfspraul>
for electronics in general, I think there is no problem with anything that stays under 60 degree celsius
<wolfspraul>
for the camera, I never measured exact numbers (we should), but you can still easily hold it in your hand, so I don't think it's even 60 degree? I'm not sure.
<wolfspraul>
it's too late now anyway we already sourced it :-)
<wolfspraul>
xiangfu: you can measure the exact temperature, that would be interesting
<wolfspraul>
also I think it's stable, it will heat up within the first 30 minutes or so, and then it stays stable
<wolfspraul>
it won't heat up uncontrollably and melt down :-)
<wolfspraul>
I think it's all by design... (good or bad design is still up in the air a little)
<xiangfu>
ok
<wolfspraul>
the camera consumes about 93-96 mA at 12V
<wolfspraul>
that will all be converted into heat :-)
<wolfspraul>
xiangfu: can you still hold it in your hand?
<xiangfu>
wolfspraul: yes. I can hold it in my hand.
<wolfspraul>
so what's your guess on temperature? do you have a thermometer?
<wolfspraul>
Adam has one I'm sure, he can quickly take a measurement...
<xiangfu>
I am measuring. it's about 38, 39. degree.
<wolfspraul>
that low? I think it's more, feels more to me.
<wolfspraul>
my guess would be 50 or so
<wolfspraul>
55 even
<xiangfu>
I am using a multimeter. 39~41
<wolfspraul>
I would be worried if it's 70 or more, but even then like I said, we rely on the vendor to make good stuff and we didn't object earlier.
<wolfspraul>
xiangfu: ok, I'm sure it's more, but anyway I think it's OK. We need more precise measurements at some point.
<xiangfu>
ok
<wolfspraul>
my rule of thumb for electronics is < 60 degree is OK
<wolfspraul>
70, 80, maybe you shorten the life expectancy
<xiangfu>
ok.
<wolfspraul>
above that generally no, unless it's specifically designed to handle that kind of heat
<wolfspraul>
of course lower temperature is always good, because there is also stress from warming up and cooling down (different materials)
<wolfspraul>
so if it never even warms up, even better.
<xiangfu>
yes.
<xiangfu>
wolfspraul: I met the error on compile patches in simple mode. two of them.
<wolfspraul>
saw it
<xiangfu>
after move those two patches to another folder, simple mode works fine.
<xiangfu>
another issue, recently I notice when I re-plug the usb cable(while m1 poweron) the m1 freeze sometimes
<xiangfu>
it maybe because when I plug the cable, I move the usb-jtag board.
<xiangfu>
move the usb-jtag board while m1 running will casue m1 freeze sometimes. (I found this when I test memcard in my m1)
<wolfspraul>
xiangfu: ok
<wolfspraul>
I believe Adam has made a few changes to the jtag-serial board so that one can access the memcard without being obstructed by jtag-serial
<wolfspraul>
but the problem with the usb cable remains, I agree, it's not very stable mechanically so if you unplug the USB cable you may mess with the connectors between jtag-serial and m1
<wolfspraul>
the good news is that jtag-serial is a developer-only feature, and only accessible after opening the case
<wolfspraul>
so I'm not so worried about those freezes, we can just try to make the 2 connectors fit better, which is already something Adam was working on
<wpwrak>
wolfspraul: those debug boards are the soul of murphy, it seems. first, the endless struggle we had with them at openmoko. now the M1 jtag board ...
<wolfspraul>
works perfectly fine on m1
<aw_>
wpwrak, yeah...agreed. btw...well
<wolfspraul>
the issues we had so far are all cosmetic/polishing
<wolfspraul>
like the usb high-speed fix, or the mechanical adjustment to better reach the memcard, or a very stable connection between jtag-serial and m1
<aw_>
the jtag rc2 i believe it will fit m1 connect better.
<wolfspraul>
in all this, the actual boards always worked, 100% of the time
<wolfspraul>
we almost have too much focus on the jtag-serial board, I think
<wolfspraul>
it's a developer feature
<wolfspraul>
I rather polish the end-user experience from outside the box, not when the case is disassembled and people are playing with jtag :-)
<wpwrak>
wolfspraul: the devil's usually in the electromechanical bits :) but yes, over-focus is a possibility
<wolfspraul>
jtag-serial on m1 is a success story
<wolfspraul>
the issues we have are closer to (bad) perfectionism than anything else
<wolfspraul>
I mean the boards always work, really always. never once had a problem...
<wolfspraul>
I think I have seen some cases where I had to run the reflash_m1.sh script twice, because the first time it would fail with some error
<wpwrak>
wolfspraul: but it causes freezes ?
<wolfspraul>
that looks like a jtag or software issue though
<wolfspraul>
nah
<wolfspraul>
wpwrak: xiangfu is unplugging the usb cable
<wolfspraul>
the usb cable is rather big, and the connector quite strong
<wpwrak>
ah :) that can easily cause trouble
<wolfspraul>
now, on the other side the jtag-serial is held to the m1 only with simple pin headers
<wolfspraul>
so the force needed to unplug the USB is sometimes more than it takes to unplug the pin headers on the other side
<wpwrak>
it may even be just the FTDI spewing garbage at JTAG. there should be two reset lines in there. much fun can be had with these.
<wolfspraul>
but keep in mind: this is all happening with an open case
<wolfspraul>
it's a developer-only situation
<wolfspraul>
the connector between jtag-serial and m1 is not designed for live plugging
<wolfspraul>
the sequence in which the wires connect can even cause damage
<wolfspraul>
so yes, it is a (very small) problem
<wolfspraul>
but once someone opens his case, and starts working with jtag, that's a very small issue to take care of
<wolfspraul>
same as, say, to not spill liquids onto the open pcb :-)
<wpwrak>
no cleaning with alcohol allowed :)
<wolfspraul>
to be safe, you may want to power off your m1 before unplugging the usb-jtag cable
<wolfspraul>
why would you even want to unplug it while running the unit?
<wolfspraul>
remember that we are in a developer lab situation now, someone has jtag wired up for some reason
<wolfspraul>
this is not a user at a party/event trying to use the product
<wpwrak>
you never know ;-)
<wpwrak>
hacker party ;-)
<wolfspraul>
and actually, with the case open, and the usb connector being metallic, you have to be careful to not accidentally short something even before you connect to jtag-serial
<wolfspraul>
in the bigger context the mechanical issue xiangfu pointed out is not more problematic than many other things you expose yourself to once you open the case and start working with the board
<wolfspraul>
but then, like with the other jtag-serial bugs, we shouldn't take it out of proportion
<wolfspraul>
it works just fine...
<wolfspraul>
and as Adam said we already try to make the connectors to m1 fit tighter/be stronger
<wpwrak>
yeah, often you just need to know where the traps are
<wolfspraul>
if you reach with a metallic connector directly onto an open pcb, you should already be at some alert mental state
<wolfspraul>
otherwise you better not even open the case...
<xiangfu>
:)
<wolfspraul>
xiangfu: I think I always first powered off my m1 before unplugging the jtag-serial usb cable
<wolfspraul>
not even out of running into a freeze or so like you, just general precaution
<xiangfu>
wolfspraul: yes. that is better.
<wolfspraul>
hah, I have a horrible idea
<wolfspraul>
wpwrak: Adam can put a huge blob of hot glue around all this (jtag-serial sitting on m1)
<wolfspraul>
that would be niiiiice
<wolfspraul>
that way the connection between jtag-serial and m1 will sure be stronger than the one between usb cable and jtag-serial
<wolfspraul>
(no worries, I am joking, we will not do that :-))
<wpwrak>
sounds like a solution that's worse than the problem ;-)
<aw_>
wpwrak, dis you know how david's smt vendor to go through your front.pos and back.pos files while mounting atben?
<aw_>
wpwrak, hmm...some sort of same results, good. :-) csv also they can transfer to xls in windows.
<wpwrak>
aw_: there was one thing the smt fab didn't like: i had not included the fiducials in the positions. the latest version of my scripts now does that too
<wpwrak>
aw_: pcb and smt fab package generation is just a matter of "make fab". the only thing not automated is the README. still haven't found a good artificial intelligence to do the documenting for me ;-)
<aw_>
wpwrak, already pretty good tool though.:-)
<aw_>
wpwrak, with regards to if adding fiducials in each single gerber can be determined by their skills. but it's good that i saw you added it into single gerber.
<aw_>
wpwrak, this time i asked smt technician first then decided not to add fiducial. :-)
<wpwrak>
aw_: the smt fab in spain gave us a detailed specification of what fiducials they wanted. but in the end, it seems they didn't really need them :)
<wpwrak>
aw_: (or maybe they just picked up their positions from somewhere else. there's enough redundancy for that.)
<wpwrak>
aw_: in any case, the next time, the fiducials will be perfect ;-)
<aw_>
wpwrak, exactly heard eventually here too, the super smart optical system on their smt machine seem that can cover this.
<aw_>
wpwrak, but how it did? didn't know. :-)
<aw_>
wpwrak, just liked you said; me too here, they picked up one pad or through hole then done. ;-)
<wpwrak>
aw_: i was kinda surprised they asked for fiducials at all, with so many nice pads to choose from :)
<aw_>
wpwrak, :)
<lekernel>
xiangfu, do not plug the usb-jtag board when the m1 is running, it's not made for this and there is risk of short circuits
<lekernel>
if it freezes, it's probably because it sent a break on the serial port and entered debugger mode
<lekernel>
also, some distros run crap like gpsd at every new serial port which is connected; the garbage data such things send might just well be interpreted as a break
<xiangfu>
lekernel: thanks for the info.
<lekernel>
let's not give too much importance to the remote control...
<lekernel>
any news on the libcurl timeout issues? or fixing the GUI fonts?
<lekernel>
hardoded t003 timing is fine now
<lekernel>
hardcoded
<lekernel>
libcurl related freezes and bogus characters aren't
<xiangfu>
lekernel:(remote) yes. I just ask another people to help, (libcurl) not much progress.  :(
<xiangfu>
I am take a look the check version today. if the expat can decode the html?
<lekernel>
html?
<lekernel>
oh, don't do anything complicated please
<xiangfu>
lekernel:Â Â I create a test url, is this ok for you? there is file named 'versions'
<lekernel>
yes, looks good
<lekernel>
for the patches, "versions" looks inappropriate, use "list" or something like that
<lekernel>
oh, and we should not include the DMX patches in the patchpool, since in "out of the box" mode the user probably won't have a DMX controller attached
<wolfspraul>
lekernel: it would be cool if patches were somewhat 'smart', maybe with a flag or so, and a patch could indicate if it should be skipped if there is no camera signal present, or no DMX controller
<wolfspraul>
like a command in the patch "needs camera"
<lekernel>
yeah I brought up this idea already, it's in the "other ideas" software roadmap
<wolfspraul>
not sure whether this is a good idea, but in simple mode it may help to skip patches that just don't look good, without camera, or without dmx
<wolfspraul>
ok
<lekernel>
but that's one small detail
<wolfspraul>
not very high priority
<lekernel>
if people want to get a "professional" experience, they won't use simple mode
<xiangfu>
(list) ok. I was thinking. maybe in future we do have a version in patchpool, anyway, let's use 'list'.
<lekernel>
then it's going to be a different file format, and it makes sense to use a different filename so software and people do not get confused
<xiangfu>
just checked libcurl using alarm() and sigsetjmp()
<lekernel>
ok
<lekernel>
my guess at the bug is that gethostbyname() calls alarm() again to set its 2 minute timeout