<kristianpaul>
wich kind of tracking loops had you worked with?
<wolfspraul>
kristianpaul: he's out to dinner now :-)
<kristianpaul>
oh, ok
<kristianpaul>
quick update, them
<kristianpaul>
lemay: namuru correlator (actually kinda same tp gp2021 from zarlink) is ported now to milkymist
<kristianpaul>
missing and not implemented yet in software a proper tracking and pull-in algorythm that finally allow us to get navigation data :)
<kristianpaul>
later care about fixes :)
<kristianpaul>
so osgps wich stands to open source gps, was developd/used ten years or so ago with a gp2021 chip hookedup to a ISA card on a 100mhz computer
<kristianpaul>
the code is not the best you see, i'm not a skilled coder, but still dificult to get understan how it works as too  many things are in the same file.. well
<kristianpaul>
osgps seems to implement a PLL-like methog for tracking
<kristianpaul>
dunno how it works in detail
<kristianpaul>
and btw how yo get to here ;)?
<lemay>
hah, I have to dust off those memories
<lemay>
I bumped into wolfspraul
<lemay>
:)
<lemay>
well, the tracking loop I've done was pretty much like a PLL as well
<kristianpaul>
lemay: was your work related to full software processing?
<kristianpaul>
was it offline or "real time" processing?
<lemay>
real time
<kristianpaul>
yay !
<kristianpaul>
so far the _only_ achievement about signaling was confirm code in the signal i sampled for offline prossing
<kristianpaul>
afaik i never got track, i guess because i wasnt aware osgps dint worked with complex samples..
<lemay>
you successfully correlated CA code in post-processing?
<kristianpaul>
with namuru?
<lemay>
uh, heh
<kristianpaul>
in short words i still on acquisition
<lemay>
right
<lemay>
what sort of data are you working with?
<kristianpaul>
from namuru?
<lemay>
I mean the RF
<kristianpaul>
currently sige rf fronted provides real samples,  2 bit sig/mag
<kristianpaul>
2.556Mhz IFÂ Â 16.684 mhz sampling clock
<lemay>
gotcha - you already told me that, huh
<lemay>
:)
<kristianpaul>
oh no, sorry if i missudestand you, too many info and i'm soon (1rh or so) off bed
<kristianpaul>
you are in canada right?
<lemay>
so, since you're working with real samples, your next step is to try to correlate using osgps?
<lemay>
california
<kristianpaul>
oh, nice
<kristianpaul>
about osgps well not now, i did in the past some offline processing, as i was using milkymist just for data acquisition
<kristianpaul>
but now i have namuru on milkymist, so next plan is detect correlation peak
<lemay>
sounds good
<kristianpaul>
i hope ;)
<lemay>
does the namaru software take care of all of that?
<kristianpaul>
namuru is implemented in the fpga, lets said is the hardware DSP for all this, afaik no current software support for it that i'm aware off
<kristianpaul>
s/off/of
<kristianpaul>
so no no care of all that
<kristianpaul>
it will when the software side to drive the namuru will be developed/ported? for milkymist
<kristianpaul>
then we can call it milkymist  gps baseband soc i guess ;-D
<lemay>
gotcha. So you're going to interface the FPGA on the milkymist with the RF front end - the SE4162T-EK1 - and use it to track GPS
<lemay>
this sounds plausible to me
<kristianpaul>
yes thats already done
<kristianpaul>
actually i hope from now that is missing is software side
<lemay>
Yea, I mean the whole thing - the tracking GPS part - that's plausible
<lemay>
what sort of CPU will you use?
<wolfspraul>
hey, Milkymist is a CPU :-)
<kristianpaul>
tell is a SoC..
<lemay>
something in the milkymist - the LatticeMico32?
<kristianpaul>
milkymist uses a lattice  mico32
<kristianpaul>
yes
<kristianpaul>
but yes CPU is okay i think
<lemay>
haha, I don't know enough about the system architecture :)
<lemay>
well, I think it will work
<kristianpaul>
sure it will !
<lemay>
I designed a front end for a system that is very similar
<lemay>
correlators in FPGAs, and controlled by an x86 running windows, of all things
<lemay>
its a Dell with a Virtex 4
<kristianpaul>
s/tell/well
<kristianpaul>
wow wow, sounds fancy :)
<kristianpaul>
is it pusblished somwhere?
<lemay>
yea, its nifty
<wolfspraul>
lemay: can you share some sources? :-)
<lemay>
unfortunately I can't
<lemay>
but I can try to help you
<kristianpaul>
i'm open now to learn about pull-in algorythms
<lemay>
I understood the tracking loops pretty well at one point, but it will take me a bit to shake off the dust
<kristianpaul>
btw the software on the x86 worked upon accumlators? or implemented PLL directly on FPGA?
<kristianpaul>
i was told that was posible too
<lemay>
it worked on the early prompt lates from the fpga
<kristianpaul>
take your time lemay , and hang on here of course
<kristianpaul>
great, on namuru we have same :)
<lemay>
it updated the phase shift register based on those sums
<lemay>
and I suppose the code replicators, too
<kristianpaul>
code replicators?
<lemay>
yea - for the crrelation
<kristianpaul>
replicator = generator ?
<kristianpaul>
ah yeah, replica code, yes yes
<kristianpaul>
go ahead, sorry for interrupt
<lemay>
I've got to go afk for a few minutes
<lemay>
be back in 5 or so
<kristianpaul>
ok i think i'm going bed now, my head is not feeling good...
<lemay>
ok
<lemay>
nice talking to you
<lemay>
if you come up with any questions let me know
<lemay>
I am in #elphel a lot
<kristianpaul>
last question for you is about how you managed to your software be wideband and narrow band,
<kristianpaul>
also how to manage doppler, and when the receiver is moving
<kristianpaul>
okay, nice to meet you too lemay
<lemay>
Well, your sampling rate will allow you to adjust for doppler
<kristianpaul>
read you later
<lemay>
and you need to tune your tracking loops depending on what dynamics you want
<kristianpaul>
and how to manage that satellite moves... i mean i have this early promt late, but how i do correlate that data? is tha pull-in about?
<kristianpaul>
i really need to understand an algoythm for it..
<kristianpaul>
yes i need to learn how in depth, at least to implement that for namuru, as i dont get that part clearly from osgps code... :|
<lemay>
the satellite motion is part of the doppler estimation
<kristianpaul>
ohh
<kristianpaul>
i tought was apart
<lemay>
I mean, that thing is moving at a jillion miles per hour, right?
<lemay>
so it has a doppler relative to you, even when your stationary
<lemay>
your tracking loops just care about the combined doppler
<lemay>
your combined doppler will be fairly insignificant compared with the correlation period
<lemay>
or, your delta doppler
<lemay>
I just started spouting gibberish, huh
<lemay>
so, you can tell what the combined doppler is, in general
<kristianpaul>
so whats the main issue about tracking? i mean once i detect the signal i play with... slewing code? or fixing local carrier nco values?
<lemay>
the main issue about tracking is replicating the correct code and carrier
<lemay>
you look at your early, prompt, and late correlation sums, and it tells you whether or not you are right on the signal, or if you are a little bit off
<kristianpaul>
i see, not sound complicated :)
<lemay>
based on that, you change the phase of the carrier that you are generating and you move the code forward or backwards
<lemay>
heh, are you being ironic or not? I can't tell.
<kristianpaul>
no no, no ironic
<lemay>
yea, conceptually it is not bad
<kristianpaul>
the faster the better i guess
<lemay>
so the PLL - phase locked loop - generates a carrier phase based on the early prompt and late sums (if I am remembering all this right.)
<lemay>
well, you have to correlate for so amount of time to generate your eraly prompt and late sums
<lemay>
like, 20 milliseconds is standard
<kristianpaul>
yes
<lemay>
so you get your updates at 50Hz
<kristianpaul>
yes, thats navigation rate per satellite right?
<lemay>
you update your tracking loops at 50hz
<lemay>
sounds right.
<lemay>
but thats different from the tracking loop
<lemay>
the tracking loop is adjusting the PLL at 50Hz, based on those correlation times
<kristianpaul>
tracking loop update in less than a 1ms i remenber, right?
<kristianpaul>
hum..
<lemay>
the nav data is basically checking the sign of the prompt signal
<lemay>
well, depends on your implementation
<lemay>
if Namuru does 1ms that's great
<lemay>
and maybe that's normal, I haven't thought about this in a while - maybe tomorrow I'll be saying to myself, 'yea, duh, of course its 1 ms....'
<kristianpaul>
i think is less 1ms is too tight, but yes it does
<kristianpaul>
he sure,
<lemay>
so, narrowband vs wideband - I am not sure I understand the question
<lemay>
Yea, that sentence is kind of strange. I'd ignore it.
<lemay>
Essentially you change modes when you go from acquisition to tracking - in acquisition you are searching the entire code/doppler space, and once you have acquired, you don't need to search the doppler space - just the early prompt lates
<rejon>
most of my comments had to be removed because were too personal and stinging
<rejon>
esp. the one about the open hardware logo being a broken gear
<wolfspraul>
ha
<wolfspraul>
you are right, never thought about it
<wolfspraul>
broken gear :-)
<wolfspraul>
rejon: phew, so much text [iftf] - do I have to read all that?
<wolfspraul>
I scanned over Bunnie's comments and I share all of those views.
<rejon>
no
<rejon>
its pretty comprehensive look at shanzhai
<wolfspraul>
Bunnie does have a real and deep understanding of these things.
<rejon>
concludes that chapter
<rejon>
i think i just repeat most of the things you put in my head
<rejon>
but my comments were mostly removed by my request
<rejon>
i wanted that gear one to go in
<rejon>
anyway, next
<rejon>
just an item for the news
<xiangfu>
wpwrak, someone ask atBen in mailing list: (1) can it be connected to a Arduino microSD shield? I am using Digi
<xiangfu>
Xbees at the moment but I would rather switch to atben if possible
<xiangfu>
wpwrak, I don't know  how Arduino software drivers works. so don't know how to answer :(
<wpwrak>
no, it won't work with the arduino microSD. arduino doesn't provide all the signals on the uSD.
<wpwrak>
and of course, you would also need to write a driver, etc.
<xiangfu>
ok. got it
<qi-bot>
[commit] Werner Almesberger: bitcmp/: little utility to find which bits differ between two files (master) http://qi-hw.com/p/wernermisc/08a13cd
<wpwrak>
(i hope :) have't tried three nodes myself yet
<`antonio`>
wpwrak, ok :) i'll let you know how that goes !
<jivs>
Hi wpwrak, One of the atben is giving this error
<jivs>
i check the nanonote detects other atben, so i suppose kernel is fine
<jivs>
i tried on another nanonote as well same error
<jivs>
at86rf230 spi32766.0: Non-Atmel device found (MAN_IDff ff)
<jivs>
[Â Â Â Â 3.240000] at86rf230: probe of spi32766.0 failed with error -22
<jivs>
what it could be? anything related to atben hw?
<`antonio`>
wpwrak, 3 nanonote connected together with atben, that worked, thanks
<wolfspraul>
wow
<wolfspraul>
`antonio`: three?
<`antonio`>
yes
<Ayla>
interesting
<jivs>
4 of them now!
<wpwrak>
jivs: (error) sounds like the atben card is missing or makes bad contact
<wpwrak>
whee ! largest atben network on the planet ! :)
<kristianpaul>
feels bad not buying/supporting some atben..
<wpwrak>
traitor !!! :)
<jivs>
wpwrak, i tried few times and on few ben nanonotes..
<jivs>
but i will try again if any device can detect it..
<kristianpaul>
no rush with tuxbrain. but paying lot of taxes make me keep away :(
<kristianpaul>
may be sharism can sell me soem atben? :)
<kristianpaul>
`antonio`: what are your plans with the atben?
<`antonio`>
kristianpaul, I am testing atbens as part of a project and hopefully tomorrow i'll do a video
<`antonio`>
wpwrak, for that jivs error: one atben is faulty.
<wpwrak>
`antonio`: :-(
<wpwrak>
`antonio`: if you want to analyze what's wrong, you could run the production test software on it
<wpwrak>
`antonio`: most likely, the GPIO test would spot something
<wpwrak>
`antonio`: the test is in this script: ben-wpan/prod/atben
<`antonio`>
ok
<`antonio`>
i'll let you know how that goes
<wpwrak>
there's actually very little that can go wrong on atben. any failure wold have to be a short (foreign particle ?) or a solder joint that failed
<wpwrak>
for failed solder joint, only a joint on the transceiver itself or the crystal would make it become unresponsive
<wpwrak>
for a short, add the capacitors as candidates
<wpwrak>
`antonio`: in your case, you don't need the atusb side (i.e., later tests of the atben would fail without atusb to talk to around)
<`antonio`>
wpwrak, i went through that already last week and I had some problem, i'll let you know if I got that working
<`antonio`>
also because i'll need your help :)
<wpwrak>
hehe :)
<qi-bot>
[commit] Werner Almesberger: bitcmp/bitcmp.c: added indication of direction of bit flip (1 -> 0 or 0 -> 1) (master) http://qi-hw.com/p/wernermisc/dd0c4ec
<methril_work>
wpwrak, in your fw adventures do you ever have stack problems?
<wpwrak>
methril_work: so far, i never hit any. at least not that i know ;-)
<methril_work>
wpwrak, i`m in this nightmare at work...
<methril_work>
i know because a wonderful processor feature that resets the preocessor if a StackOverflow occurs
<wpwrak>
can you disable the reset ? (-:C
<methril_work>
yes, but then it gives undetermined behaviour
<methril_work>
it`s worst disabling it
<wpwrak>
excellent. then you can blame the hardware :)
<methril_work>
i balme all the time!! :)
<methril_work>
s/balme/blame/
<wpwrak>
:)
<wpwrak>
in hardware we distrust :)
<methril_work>
not in this HW :)
<kristianpaul>
arggg cannot exec `cc1' i hate rpm NOW
<kristianpaul>
what's license for this mmtp_i2l.pdf btw¿
<kristianpaul>
s/¿/?
<lekernel>
wtfpl
<kristianpaul>
no other license please
<DocScrutinizer>
yay exception on stack overflow - cool feature
<wpwrak>
PIC, i guess ? :)
<lekernel>
actually I wonder why no other arch implements this SPLIM register
<lekernel>
it's not even particularly hard to do
<lekernel>
we should add that to lm32 :)
<wpwrak>
lekernel: why ? the MMU will catch it nicely ;-)
<lekernel>
SPLIM is much easier to support in RTEMS than a MMU-based system
<lekernel>
and it will take ages before Flickernoise runs flawlessly on Linux
<wpwrak>
happily notes the now the possibility of running flickernoise on linux is being considered :)
<wpwrak>
but yes, certainly nothing trivial
<lekernel>
I have nothing against Linux... except that it doesn't work, and getting it to work takes 50-100x as much time as RTEMS for equivalent tasks
<wpwrak>
but when it works ... :)
<kristianpaul>
people will blame the 80Mhz cpu..
<wpwrak>
blame or dislike ?
<wpwrak>
isn't there still quite a bit of spare room in the fpga ? maybe you could add more cores ;-)
<kristianpaul>
yes, sorry. dislike
<kristianpaul>
oh sure
<kristianpaul>
all is posible ! ;)
<wpwrak>
simplify it and make a decacore. more than all the other big players ;-)
<lekernel>
in fact, a decacore might work right now
<wpwrak>
add some branch elimination logic for the bogomips loop, and you'll have stellar values there, too ;-)
<lekernel>
except that there's no software support for it ofc
<wpwrak>
lekernel: who cares about sw support ? it's all marketing :)
<kristianpaul>
just lack software support, what about hdl part? is that easy as just adding another lm32 to the shared bus?
<wpwrak>
(branch elimination) when you take a branch, remember where it went and what the condition was. then have a comparator on the program counter that implicitly executes the branch when incrementing into the address of the branch instruction iff the condition is met. voila, removed at least 1 instruction cycle :-)
<wpwrak>
now quick, where do i file the patent :)
<lekernel>
kristianpaul, if you don't want cache coherency (which could be a problem depending on the software) yes
<lekernel>
if you want cache coherency... you have to dig into the CPU pipeline, and since people seem already afraid of the simpler MMU this has little chance of happening
<lekernel>
though the LM32 cache is write-through, so all you have to do is broadcast writes to all cores. not too hard.
<wpwrak>
i somehow feel that we may see more cores pop up before too long :)
<lekernel>
wpwrak, phew, I'm not that optimistic
<lekernel>
among the current people I don't think anyone would pull that off
<lekernel>
and wrt finding new people, my google analytics reports still feel like a spit in my face
<lekernel>
so... it will be hard
<wpwrak>
lekernel: ah, i was thinking that you might have had an inspiration of the "hey, this would be EASY" kind :)
<wpwrak>
(followed by a few hours of furious hacking. then a few more days, realizing that it wasn't all that EASY, but still doable. etc. ;-)
<lekernel>
can you believe it? the elektor article, run in 3 different languages (and soon 4), generated so far exactly 2 people following the project and 1 board sale
<wpwrak>
wow. does elektor have so little reach these days ?
<lekernel>
seems so
<lekernel>
even slashdot had better results (and it took less time to write the article, too), despite the trolling
<wpwrak>
heh :)
<wpwrak>
well, a good article is also something you can point people to and you can reuse some of the material. so it's not a waste of time
<lekernel>
so atm i'm trying xcell, aimed specifically at people who are not afraid of fpga's to start with
<lekernel>
some articles are also "syndicated" in publications like eetimes
<wpwrak>
yeah. maybe that'll get some more developers aboard
<lekernel>
so, atm I rather feel the need to fix that huge unpopularity problem rather than mess with multicore lm32's ...
<wpwrak>
maybe multicore will get people excited :)
<wpwrak>
i think once linux runs well, this may help. lowers the barrier of entry quite a bit if you have a familiar operating system.