<wpwrak>
maybe they'll open source it ? then someone can port it to the freerunner ;-)
<wolfspraul>
are there parts not open sourced yet?
<wolfspraul>
yeah maybe they'll do a code dump in the end, and a few pieces can be rescued to OpenWrt and other healthy projects
<kristianpaul>
all gui is closed source so far i now.. but people said it uses OE
<kristianpaul>
s/now/know
<wpwrak>
(open) uh, no idea really. just assumed :)
<wolfspraul>
yes I think so (OE), or they forked or something
<wolfspraul>
I was involved in the very beginnings of this project, when it was still called Maguffin in 2003/2004. Sad to see it end like this, but I cannot say that I lost much time over it the last few years :-)
<wolfspraul>
In fact somewhere around 2006, I refused to continue working on it, causing a nice little run-in with my boss.
<wolfspraul>
development was so slow that we fell behind our own hardware components! :-)
<wolfspraul>
the first few years everything was hardcoded to one particular screen resolution. problem was - bad sourcing feedback - that screen resolution was unusual (forgot which one, something high-end at the time it was chosen).
<wolfspraul>
then it became harder and harder to source that screen, crazy hard in the end.
<wolfspraul>
finally it was not sourcable anymore and the entire software stack came down and had to be redone with another resolution (or supporting multiple).
<wolfspraul>
all this took years
<wolfspraul>
so many mistakes we understand so well now. Like - be super careful choosing the 'latest and greatest' chip or component.
<wpwrak>
"do not hard-code the resolution" ;-)Â Â (well, i sometimes do that too :)
<wolfspraul>
HP still plans to "explore options to optimize the value of WebOS software going forward."
<wolfspraul>
(I don't like how copy/paste creates this auto-url...)
<wolfspraul>
have to clean it through a text editor
<wolfspraul>
"optimize the value", let's see what that means in the end
<wolfspraul>
maybe code dump, yeah. I don't think anybody has the guts to make devices for it anymore.
<wpwrak>
probably just management blabla
<wolfspraul>
yes they need some lessons in clear speaking
<wpwrak>
weak lie-ability :)
<DocScrutinizer>
I wonder what's going on at Samsung and with Raster's Linux
<wpwrak>
yeah, the most secret project in existence
<DocScrutinizer>
there's been a 2.3 pages press release with a bit of block diagrams with all the closed components colored blue
<DocScrutinizer>
been quite a while since
<DocScrutinizer>
and Raster notably stopped spreading teaser rants across the channels every now and then, since also quite a while
<wolfspraul>
Samsung is one of the few companies where I like their strategy (amazon being another one)
<wolfspraul>
maybe not 'like' but 'understand'
<wolfspraul>
Samsung's strategy is "we make devices with _all_ software we can get"
<wolfspraul>
wonderful
<wolfspraul>
that works
<wolfspraul>
also very unique, afaik nobody else has that strategy
<wpwrak>
you get a big of that with oscilloscopes. a tek or agilent will have the basics plus a number of expensive extension packages. some of the asian competitors include these features in the base version.
<wpwrak>
s/big/bit/
<DocScrutinizer>
probably it never occurred to the asian folks you could also *sell* software rather than just *copy* it
<DocScrutinizer>
seems to me the concept of copying is much closer to the asian mentality than the concept of selling IP
<DocScrutinizer>
but then I don't know a shit about asian mentality at large
<wpwrak>
i guess it's materialism at work. you sell material goods. you copy the immaterial ones. makes perfect sense :)
<DocScrutinizer>
yup, that's what I meant I think
<DocScrutinizer>
imitation is a compliment in Asia afaik. So how could you ask money for copies of whatever
<wpwrak>
even better :)
<wpwrak>
i mean, non-corporate westeners think very much alike. if "file shearing" is so easy, how could it be wrong ?
<DocScrutinizer>
oooh I think each westerner knows it's basically wrong. Just nobody cares anymore
<DocScrutinizer>
yet you can hear all sorts of the weirdest excuses why they do it _nevertheless_
<DocScrutinizer>
most popular one "I wouldn't buy it anyway"
<wpwrak>
wolfspraul: btw, how are the bens selling these days ? constant trickle ? or some changes ?
<wolfspraul>
trickel
<wolfspraul>
trickle
<wolfspraul>
:-)
<wolfspraul>
I think my rough plan is like this - first really finally get my second product, m1, into stock
<wolfspraul>
it's crazy I say this since January but well, it's still not done
<wolfspraul>
after it is in stock, back to marketing
<wolfspraul>
great shop
<wolfspraul>
nice and clean and good looking
<wpwrak>
things always take longer than you think ;-)
<wolfspraul>
easy shipping options
<wolfspraul>
want to work on backend too, openerp
<wolfspraul>
and come out with improved openwrt images or other ben software
<wolfspraul>
the Linux 3.0 bot messages were annoying but also encouraging :-)
<wolfspraul>
I think we can get a lot of music software to the ben
<wolfspraul>
not just music player, also more things like tracker, all the way down to metronome :-)
<wolfspraul>
I will just continue with the Ben, basically.
<wpwrak>
rosegarden ;-))
<wolfspraul>
then have to find partners who see the technology and potential and want to turn the tech into a different kind of product, or just move it forward to Ya.
<wpwrak>
yup, the ya should be our real platform. the ben is still a weak basis. aging and not fully open.
<wolfspraul>
totally agree
<hamnegga>
Is there a special kind of solder to use for electronics, especially 2.4GHz hardware components.  I have some Oatey Safe Flo Lilver Lead Free solder, and another from archer that's rosin core solder.  Would either work, or should  I use neither.  I was thinking the lead free, but it's typically used for plumbing/heat-hot water piping.
<hamnegga>
the rosin core is 60/40 whatever that means, and the silver/lead-free doesn't say
<wpwrak>
don't use plumbing solder. it has the wrong chemistry for electronics.
<wpwrak>
60/40 is a common solder that works well. lead-free solder is usually a bit harder to work with.
<wpwrak>
if you do SMT components, you'll also have to add extra flux. there RA/RMA (rosin), water-soluble, and no-clean. i find the water-soluble fix the most convenient to work with. note that "water-soluble" doesn't mean it will come off easily. you still have to do a good amount of scrubbing and rinsing.
<hamnegga>
oh, cool, actually then I don't have to resolder the little brown thing I attached to my GPU when it broke off.  I thought led was a bad conductor.  The card has been working up to par, but wasn't sure what the little brown rectangle was and thought I might have lost a shader core or something in the process. Â
<hamnegga>
3 in the morning though, I gotta go to bed and get up for work in 4 hours so, I'll talk to u tomorrow about soldering up some extra custom wifi dishes.  I might actually go at it again.  Would additional uhf antennas on the back of a direct tv dish benefit at all for 2.5 GHz, even if I kept the male and female respective, or would it just add more length and dBM and dBi loss
<hamnegga>
I thought the more silver would be better for 2.4GHz/wifi, because that's what all their components use, like sma, tnc, and bnc regarding microwaves.
<hamnegga>
you need to be an expert I guess and each connector nevermind noobish soldering job is bound to lose at least 1-5dBi
<xiangfu>
try to boot linux 3.1 on nanonote:
<xiangfu>
    0.000000] Linux version 3.1.0-rc2+ (xiangfu@macbook) (gcc version 4.5.2 (Linaro GCC 4.5-2011.02-0) ) #1 PREEMPT Fri Aug 19 16:29:03 CST 2011
<kyak>
xiangfu: does it boot?
<xiangfu>
yes.
<xiangfu>
works fine.
<xiangfu>
one little thing I forget to change to load '/etc/preinit'
<xiangfu>
now I am try to move those patches to openwrt-xburst and try it inside openwrt.
<kyak>
great :) congratulations!
<xiangfu>
kyak, we should think about how to merge the work from qi-kernel.git to openwrt-xburst.git patches. :)
<kyak>
is 3.1 avialable in qi-kernel.git?
<kyak>
xiangfu: i think the main problem is that openwrt trunk is still using 2.6 for xburst
<kyak>
the patches would be too big
<xiangfu>
I saw the 'jz-3.0' branch.
<kyak>
someone must transfer this work to openwrt directly
<xiangfu>
almost same as 2.6 patches in upstream.
<xiangfu>
I direct work on latest upstream 3.1-rc2
<xiangfu>
I mean I direct move 2.6.37 patches on top of 3.1-rc2.
<xiangfu>
kyak, yes.
<xiangfu>
even more sync with linux upstream.
<kyak>
right now it's 2.6.37 in openwrt trunk
<xiangfu>
kyak, today I forward all u-boot and linux patches on top of last upstream :)
<kyak>
i remember lars told several weeks ago he was going to update it to 2.6.39. I think it's time to update to 3.1 :)
<xiangfu>
kyak, by the way I think I will release a test/debug version recently.
<kyak>
xiangfu: hope your patches will make it into openwrt...
<xiangfu>
kyak, I saw there are already some target have linux 3.1
<kyak>
yeah
<kyak>
actually, even malta has it
<xiangfu>
kyak, let me check now if there is 3.1 in openwrt recently.
<xiangfu>
kyak, our last rebase have 3.0
<kyak>
yeah, but not for xburst
<xiangfu>
yes not for xburst.
<xiangfu>
I mean "no, not for xburst"
<kyak>
:)
<xiangfu>
Chinese and English grammar ;D
<kyak>
btw, "yes, not for.." sounds perfectly find in Russian :)
<kyak>
*fine
<kyak>
you can even say "yes, no, maybe" and this still make sense
<rjeffries>
Zigduino with Contiki OS should provide an interesting end point for Ben w/ATben to reach out and touch over 802.15.4 and (eventually) 6LoWPAN
<kyak>
xiangfu: ah yeah, that's good thing. Are nightly images copied to testing/ automatically or by hand?
<viric>
Hm
<viric>
question, dear hw people
<viric>
Do you know of any kind of usb-connected lamp that I could switch on and off in linux?
<viric>
I have some computers away. And I'd like of people to be 'notified' that some processing is ready
<viric>
s/of //
<rjeffries>
ah I see. cool idea
<viric>
hm nothing new, I imagine :)
<kristianpaul>
ring ring :)
<viric>
kristianpaul: ring ring?
<kristianpaul>
viric: lol. i mean you can use a electric bell, nv..
<viric>
kristianpaul: do you know of a usb belL? :)
<kristianpaul>
afaik i dont ;)
<viric>
those I gave the link cost $99
<viric>
that's mad
<viric>
it's a usb led.
<larsc>
nothing compared to the $500 ethernet cable
<xiangfu>
kyak, Are nightly images copied to testing/, no.  only the image like '08172011' it's for release but have a little problem. :( that is the plan, hope we don't have image like '08172011' any more, mean don't have testing image anymore :D
<viric>
larsc: there? Impressive :)
<rjeffries>
viric maybe you need to kludge together a little arduino-ish solution
<rjeffries>
if you wanted to you could use your BEN and a
<rjeffries>
the next nanonote if there is a next nanonote needs among other things more i/i e.g. i2c, some gpios that can be used without using the 8:10 (microSD) port yada yada yada. maybe even USB host or OTG
<viric>
no no
<viric>
I want the solution to be *cheap*
<viric>
and zero effort. using the linux LEDs interface :)
<larsc>
and now!
<viric>
Exactly!
<viric>
I can't believe noone thought of a usb light controlled by software :)
<wpwrak_>
viric: you could use a C8051F326 plus a LED. maybe add a transistor. not too expensive.
<wpwrak_>
viric: thre a USB stack for it in the f32xbase project :)
<wpwrak_>
viric: including in-circuit programmer circuit for the Ben, etc.
<wpwrak_>
viric: afaik, the c8051f326 is the cheapest/simplest readily available solution for this sort of thing. (and without giving your money to evil FTDI)
<wpwrak_>
ah, wait. there's cheaper: an attiny with v-usb. some of them also don't need a crystal.
<wpwrak_>
viric: also some of the USB PICs can operate without crystal, but i don't know if they have a better price point for what you need.
<larsc>
even simpler ftdi + led
<wpwrak_>
rjeffries: using the Ben is also a nice idea ;-)
<wpwrak_>
larsc: ftdi is evil. that's like buying from apple :)
<larsc>
wpwrak_: why?
<wpwrak_>
larsc: they don't document their chips well enough for proper free software drivers to be written. there's an amazing amount of reverse engineering and guesswork in these drivers, and if you have a recent chips, it's hit or miss whether things work or not.
<wpwrak_>
larsc: ironically, they seem to hate Open Source
<viric>
I have not had troubles with ftdi chips
<wpwrak_>
larsc: what they want you to use is their closed source library. they offer it for linux as well, but ...
<viric>
(maybe thanks to the efforts of reverse engineers :)
<viric>
I'd prefer a light brighter than a LED though
<wpwrak_>
viric: if you just use serial, then you're fine :) also the serial protocol engine (for jtag and such) in some of their pricier chips seems to be well-understood. but when you get int bit-banging, ...
<viric>
500mA at 5V give for 2.5W of light :)
<viric>
wpwrak_: I only used serial.
<wpwrak_>
multiple LEDs ? high-power LEDs ?
<wpwrak_>
or use a relay and connect some multi-kW halogen ;-)
<viric>
I'm really not that interest to build the solution myself now :)
<viric>
interested
<wpwrak_>
the circuit would be quite simple
<viric>
So, I either find something built that works on linux, plug and "echo 1 > led", or I'll go without.
<viric>
I know I know
<rjeffries>
viric you remind me of me
<viric>
For $99 I could buy a sheevaplug; it has two leds with proper kernel interface :)
<viric>
rjeffries: I'm simply proud of having better things to do ;)
<rjeffries>
point well taken
<viric>
haha
<kristianpaul>
yes pic pic !!
<kristianpaul>
:p
<kristianpaul>
viric: you can build a pinguino board (based on a pic18f2550) for less than 10usd in my countri
<kristianpaul>
actually there is python/c++/java code for usb comuncation but no linux support...
<kristianpaul>
well, it can emulate a serial device and cheat by seriall;)
<wpwrak_>
a serial cheater ;-)
<kristianpaul>
yeah
<kristianpaul>
viric: if you are near  spain in think a guy sell then
<kristianpaul>
i actually tried with python but threads we're anoying me at than time..
<erikkugel>
Hey guys, I need to update a package from a feed (GNU Pem) -Â Â a new version came out which has special Nanonote-friendly tweaks. How would I go about something like this? What's the procedure to update a package so that future pulls use a new version of it? I thought I'll ask around before emailing Xiangfu directly...
<erikkugel>
let me know if the question is not clearly worded...
<mth>
you mean automatically fetching the latest version, or doing a manual version upgrade?
<erikkugel>
I mean doing a version upgrade. I ported PEM a month ago at version 0.7.8, but the developer added some new features especially for the Nanonote in 0.7.9. What I would like to ideally do is to edit/replace the current Makefile with a new Makefile on the servers from which the feeds are pulled.
<erikkugel>
:)
<rjeffries>
wpwrak kristianpaul No hablo Espaniol. LOL
<Artyom>
hi kristianpaul
<kristianpaul>
hello Artyom
<Artyom>
How is your success with namuru+osgps? ;)
<kristianpaul>
namuru accumualtors are operationl now
<kristianpaul>
afaik i dint measure its opetation in depth yet
<kristianpaul>
actuaylly
<Artyom>
and what are your plans? What is your next step?
<kristianpaul>
i have a concern now, because i have to fire by software the accum interrupt  signal...
<kristianpaul>
plans, sure, i'm goint to improve some test tool to support now right PRN codes,
<kristianpaul>
also collect that accumulator data and plot it
<kristianpaul>
then guess a threshold from wich in can improve the acquisition loop
<Artyom>
I would suggest the following easy test:
<Artyom>
Choose a settelite that is definitly visible. Set it's prn number. Set code_reference_frequency to default value (2.046MHz). Set carrier_frequency to zero doppler. Then pass through all delays and record values in memory. After that set next doppler frequency. And repeat. This way pass through all doppler frequencies.
<Artyom>
Doppler frequency step can be 1000 Hz
<Artyom>
Delay step can be 1 or two half-chips
<Artyom>
Finally move all values from memory to the file and plot the result
<Artyom>
You should see one peak in the plot
<Artyom>
This can help you to check what is your noise floor and what is your peak maximum.
<kristianpaul>
what registers have effect in doppler freq? carrier nco?
<Artyom>
yes only carrier_nco
<Artyom>
of coarse doppler affects also code_nco but this affect is negligble
<kristianpaul>
btw, where you the that 2.046MHz value?
<Artyom>
This is because code_nco works with double chip rate (2*1.023 MHz) as I remember
<kristianpaul>
hum
<kristianpaul>
i wasnt aware of that i'll recheck my notes :)
<kristianpaul>
Artyom: so how is work from your side?
<kristianpaul>
btw are you reading some RTC or similar for keep measurememnt timing constant?
<kristianpaul>
or doest matter yet to care about it..
<Artyom>
what do you mean by "timing constant" and "RTC"?
<kristianpaul>
i modifify namuru to clear after every clock cycle status, new_data and ch0_prn_key internals registers
<kristianpaul>
also in software i have to enable ch0 and set clear status flag
<kristianpaul>
my point is, i still dont like the idea that the accum int signal is fired by software it self
<kristianpaul>
and not from know constant timing source
<Artyom>
I've spent a lot of time on playing with hardware... But with little success. I couldn't achive stable tracking. I recorded correlator outputs and then plot the result in scilab. The best result that I saw - is couple of bits (like in the picture that you showed me). At the same time the same code for tracking works fine on PC (program that uses soft-correlator from osgps).
<Artyom>
so you always have new_data=0?
<kristianpaul>
no
<kristianpaul>
well i changed namuru code a bit from last time we talk
<kristianpaul>
like adding  a exclusive enable signal for channels
<kristianpaul>
and the prn key clear i pointed you earlier
<Artyom>
you clear status_read register by writing to special memory address?
<kristianpaul>
yes
<Artyom>
(that's funny - I've done the same thing in my design ;) )
<kristianpaul>
dont you ask you self if that namuru code really worked as it was published?
<kristianpaul>
anyway this is getting better :)
<Artyom>
This question raised so many times during last two weeks. Before I gave up today to fire tracking loop - I tried everything: switched prompt-early-late... And I and Q... My last idea is to rework everything... Starting from pc-program that models hardware and finishing with reworking all namuru-code. And making exhausting testing on every stage.
<kristianpaul>
you said having problems with tracking loop,
<kristianpaul>
so i wonder you can make a plot of it and compare with your expected signal some how...
<Artyom>
yes, I can plot it. And I made a lot of plots. But it's difficult to debug tracking loop in hardware. Because each time it starts to work new data is comming. I cannot repeat the same data several times :(
<kristianpaul>
Artyom: btw at #ephel channel there is this guy called lemay
<Artyom>
I've seen your conversation in the history :) He is experienced in GPS ;)
<kristianpaul>
yeah :)
<Artyom>
time to sleep. gn ;)
<kristianpaul>
bye !
<kristianpaul>
okay lets move some stuff to rtems...  no time to deal with gettng linux to boot again..