<kristianpaul>
plus a wearable antenna, all done ;-)
<kristianpaul>
ha, long mail :)
<kristianpaul>
yeah, SigE is very good writing shor datashetets ;)
<wolfspraul>
rjeffries_: which manufacturer sells a 1ghz arm for < 5 usd ?
<wolfspraul>
my point was a price comparison to fpga and I didn't want to mislead by using too low a number for the high-end arm asic
<wolfspraul>
a quick check on digikey suggests that 15-20 usd is even too low, you'd have a very hard time sourcing even an 800 mhz chip at that price range
<wolfspraul>
in low volume, it may easily be 30 USD and more
<wolfspraul>
looking at Freescale ARM right now, for example
<wolfspraul>
none of the 800 mhz or 1 ghz variants are in stock, phew
<wolfspraul>
USD 23.22 if you buy one, going down to USD 18.28 if you buy 100
<wolfspraul>
my number of 15-20 USD for a 1 ghz arm was probably a bit low, for our quantities
<wolfspraul>
as with fpgas, there are many variants, prices may vary considerably depending on which features exactly you have in the chip. mhz is just one parameter of many.
<wolfspraul>
let me know what you have in mind for 5 USD :-)
<wolfspraul>
oh wow, I rarely look at ARM prices, but I am so surprised how expensive the TI OMAP are
<wolfspraul>
40-70 USD at digikey, even for the 500-600 mhz range
<wolfspraul>
no wonder mediatek and now spreadtrum are taking the market from the bottom
<wolfspraul>
I get two full Android smartphones for the price of one TI OMAP chip :-) (exaggerating, but it gets close)
<wpwrak>
kristianpaul: there you have nice and proper for all the chips, except for the SE2436L, the only one with a built-in balun. now really, how does a bloody balun change it from something that's okay to tell everyone to a piece of information you have to beg them for ?
<wolfspraul>
wpwrak: I think there's a trend to go closed. What do you think?
<wolfspraul>
it's a bit hard for me to follow/judge with so many companies and datasheets. and we so radically focuse on those that do have full datasheets, even if it means to make an unusual selection or design.
<wolfspraul>
in the SiGe case, I had a meeting in Hong Kong already agreed to, but didn't want to go without some more real progress from kristianpaul. That was about a year ago :-)
<wolfspraul>
eventually we'll have that progress, then I see whether my email contacts still work there and still want to meet :-)
<wolfspraul>
after that I know more about SiGe's IP and datasheet policy/strategy/etc
<wpwrak>
i don't really see a trend. it's more like company-specific and sector-specific styles. e.g., wlan is usually closed, ieee 802.15.4 usually open, etc.
<wolfspraul>
yes, I would agree
<wpwrak>
then companies like atmel, skyworks, rfmd are usually open while microsemi are closed and sige half-half (to pick examples from the RF front-end world)
<wolfspraul>
new semiconductor startups are almost always very closed I found
<wpwrak>
yes, they have too much to fear :)
<wolfspraul>
once you get to the level of passive components or other 'low level' semiconductors, it's mostly open
<wpwrak>
not enough money to hire mercenaries ;-)
<wolfspraul>
once you move into anything baseband/rf, it gets very closed again
<wolfspraul>
it's like the baseband lives in a parallel reality or something
<wpwrak>
yup, complexity is a factor
<wolfspraul>
no it's not just C code running in a core, it's 'magic'
<wpwrak>
;-)
<wolfspraul>
so much fuss about basebands and dsp, really
<wolfspraul>
mostly closed, I'm constantly looking for more documentation on such chips, but hard to find
<wpwrak>
well, there's an active patent war in that area, so ...
<wpwrak>
particularly as you move up to the higher performance items
<wolfspraul>
CMOS image sensors, also very bad
<wolfspraul>
maybe the same for those radar chips Sebastien is talking about sometimes?
<wolfspraul>
we should have a table, in which industries/areas one is likely to find high quality open datasheets, or which companies are known to have open/closed policies
<wolfspraul>
the problem is that the judgment is so subjective
<wpwrak>
heh, that could be a nice "map"
<wpwrak>
(judgement) you the company's judgment whether to be open or close, or ours whether they are ?
<wolfspraul>
ours whether they are
<wolfspraul>
actually your mail, as so many times, set a good standard
<wolfspraul>
make the 'grading' of open datasheets measurable
<wolfspraul>
so it's not a matter of a marketing department deciding to declare the company's datasheets 'open'
<wolfspraul>
or the matter of a fan of a particular company or technology to declare the datasheets of that company to be 'the best'
<wolfspraul>
instead, you try to break it down to provable little factlets
<wolfspraul>
in the end it's all about electrons and physical phenomena
<wpwrak>
yeah, i think it's usually quite black/white. there are not so many corner cases where it's not so clear whether they're open.
<wpwrak>
one set of corner cases would be simply bad documentation, where you can't decode what it's actually meant to say
<wpwrak>
another set of corner cases is detail information that is willfully suppressed, even though the rest of the manual is open. one example would be the TI CC2591. there, they're very tight-lipped about the transceiver side of the RF interface: http://focus.ti.com/lit/ds/symlink/cc2591.pdf
<wpwrak>
in particular, they don't mention the impedance. the reason is that they don't want you to use this RF frontend with transceivers from other companies (they say so somewhere in a support forum)
<wpwrak>
this omission isn't easy to spot. and you can in fact find some clue as to what the impedance is, but it's all messy
<wolfspraul>
I can imagine. once you move to actually use a chip, 100 surprises await you that you would have no chance spotting from just reading docs beforehand.
<wolfspraul>
once you have software running in a chip, the degree to which it is documented is harder to assess
<wolfspraul>
you can't just look at pins then, and make sure the electronic parameters are fully documented
<wpwrak>
yeah. even if software just talks to the chip
<wpwrak>
and then there are of course those who are just a little terse. they probably don't mean to hide something, they just don't like writing
<wpwrak>
that's when R&D turns into trial and error :)
<wolfspraul>
no I think you underestimate the degree to which the documentation level is part of a carefully orchestrated business plan and model
<wolfspraul>
managers are not that stupid
<wolfspraul>
chip companies always have the problem how they get the new features of their chips through the product into the hands of the actual user
<wolfspraul>
because they are only making chips, after all...
<wolfspraul>
so if it's something NEW, how do they teach their customers (who buy the chips) how to use that new thing? how to bring it out to the user?
<wolfspraul>
so _if_ a datasheet is not open, that's because there is someone else on the outside who is doing that on a proprietary IP basis
<wolfspraul>
it's not an oversight, or a lazy or not so lazy engineer deciding how much he 'likes' to write
<wolfspraul>
I don't believe that. It's typically a very clear strategy on how to go from chip feature to end user product.
<wolfspraul>
and since there are such few copyleft hardware hackers like us, they cannot rely on us to help us with that problem, understandably
<wolfspraul>
even though one would think that open source is the perfect way to get a chip's feature actually adopted
<wolfspraul>
but in reality it's not...
<wolfspraul>
it's more important to work with a short-list of strategic customers behind closed doors
<wpwrak>
sure, but i mean something else. where they're really just tight-lipped. e.g., some control signals where you can probably guess the semantics but they're not properly specified. or where some borderline behaviour is not explained. such as "what happens if you set the enable and the (separate) disable signal at the same time"
<wpwrak>
what i mean falls more in the category of stupid little details that add one prototype/test run to your process because you can't be quite sure from the data sheet
<wpwrak>
but yes, you also have the "fully closed" ones, too
<wolfspraul>
so I think for the parts where you do find high quality open datasheets, that's because that is the quickest way to get the new features/performance of those chips adopted in real products
<wolfspraul>
and conversely, the ones that are not open, that's where the quickest way to get new features into products is via proprietary IP partners who get exclusive behind-the-scenes access anyway
<wolfspraul>
and that is typically a short-list of 5-10 companies
<wpwrak>
i think a lot is also just company culture. some almost always write great documentation. plus they care about background material. they expect their customers to be engineers who understand such things.
<wolfspraul>
when it has to be more (say because of customer fragmentation), the open strategy will be faster (=work better)
<wpwrak>
and then there are the other who expect their customers to just copy the reference design and hurry on to the next project, without wasting just one brain cell on what the thing actually does :)
<wpwrak>
and yes, those who think you'll need massive hand-holding anyway :)
<wpwrak>
of course, the latter also have quite a cultural dissonance with us. we fully expect to be capable of understanding things well enough to make sense of them, no matter how hard this is :)
<kristianpaul>
wolfspraul: i contacted the guy from the gnss-sdr.ru project, i hoep he join this channel.. as is working ona  fpga + arm device integrated with osgps and namuru !
<kristianpaul>
well, at least he said that :)
<wpwrak>
tuxbrain: you were asking about when my scripted cad exploration/evaluation would be "finished". i did a bit of experimenting with extrusion, but finally realized that the simple algorithm i had in mind isn't sufficient. so i won't have something that is suitable for a fair side-by-side comparison soon. it can make pretty shapes, though :) my extruder lives here: http://projects.qi-hardware.com/index.php/p/cae-tools/source/tree/master/
<wolfspraul>
well let's see whether/when he shows up and we'll give him a warm welcome
<kristianpaul>
:-)
<wolfspraul>
hopefully he doesn't mind openly sharing all his hardware work and discoveries...
<kristianpaul>
yeah, i hope the same
<kristianpaul>
his blog is very open, software, schmatics.. board
<kristianpaul>
not bad !
<wolfspraul>
what EDA tool does he use? what's the license of the schematics?
<kristianpaul>
kicad
<wolfspraul>
cool!
<wolfspraul>
it gets better :-)
<kristianpaul>
actually he will send me a bare PCB,
<kristianpaul>
i already ordered some samples from maxim.. just to see
<kristianpaul>
of course it doesnt mean i will drop SiGE and my current work
<kristianpaul>
i cant find license afaik.. at least for PCB
<kristianpaul>
i'll ask him next time he reply
<wolfspraul>
do the steps that get you to working results the quickest
<wolfspraul>
whether that's on m1/sige, or the new arm/fpga/maxim combo
<wolfspraul>
there is nothing more motivating than getting something to work, and it helps focusing too
<kristianpaul>
sure :)
<wolfspraul>
I forgot why we went the sige route back in the day, it's already so long ago :-)
<wolfspraul>
but that was specfically after a comparison with maxim, by someone who had used both
<wolfspraul>
every chip has pros and cons, and people run into different difficulties, also depending on their own background/strengths/weaknesses
<wolfspraul>
bottom line: find the shortest path to working anything. I'm not worried about 'dropping' sige or m1
<wolfspraul>
I personally don't find the arm+fpga combo very attractive, I think the all-fpga + softcore approach is more promising. but i could be wrong :-)
<wolfspraul>
I believe there are some chips now that combine arm+fpga in one package, maybe even one die?
<wpwrak>
why not the gnuradio approach ? collect the data on the M1 (M1 for interfacing), then send it to the PC for analyzing
<kristianpaul>
dunno arm at all, but also ppc i remenber
<wolfspraul>
is there even a problem with analyzing on the m1? I don't know where kristianpaul stands now
<wolfspraul>
it's so slow that I cannot measure progress :-)
<wolfspraul>
need a more precise measuring tool I think :-)
<wpwrak>
but as i understand where things are, the problem is still to receive the bitstream into memory, no ?
<wolfspraul>
kristianpaul: I'm just making jokes on you, hope you don't mind :-)
<kristianpaul>
no
<wpwrak>
wolfspraul: yeah, i kinda wonder if he isn't just going around in circles :)
<kristianpaul>
yeah, i kwno your jokes already
<kristianpaul>
no either,
<wolfspraul>
but seriously, finding that gnss-sdr guy and trying to team up with him is awesome
<kristianpaul>
the first aprouch about offline processing was bad idea, but anyway..
<kristianpaul>
when you later discover the software you we're using havnnt suport for complex data, oh well..
<wpwrak>
kristianpaul: so you now can receive the bits from the RF chip and store them in memory ?
<kristianpaul>
yeah, but have no sense right now
<kristianpaul>
as the idea is make namuru to work with osgps
<wpwrak>
but you're think the bits you store in memory are actually the bits the chip sent ?
<wpwrak>
s/you're/you/
<kristianpaul>
yes
<wpwrak>
have you tried to generate a test pattern to verify this ?
<kristianpaul>
in simulation yes i did
<kristianpaul>
not in real hw afaik
<wpwrak>
hmm :)
<kristianpaul>
he :)
<wpwrak>
might be worth a try
<wpwrak>
not being able to make sense of the bits you receive would be quite consistent with them just being incorrect :)
<kristianpaul>
once i got namuru accumulator to work, sure
<kristianpaul>
i dunno why is not wokring well right now..
<kristianpaul>
yeah, sure, i can do that, i have sie board, so it can help to generate a know pattern and compare later in m1
<wpwrak>
for the pattern, what i mean is that you could send, say, the values of an 8 or 16 bit counter. that's something you can verify manually with the scope. then feed it into the receiver and see what bit pattern comes out
<wpwrak>
if it's correct, you know that this much seems to work. you still have the issue that you're synchronous, though, so maybe generate the pattern with a ben :)
<wpwrak>
ah, or with the SIE. even better :)
<kristianpaul>
ah yes
<kristianpaul>
wpwrak:Â Â yes yes
<kristianpaul>
i edid that with scope
<kristianpaul>
for clk, and ata signal
<kristianpaul>
i just was testing a more complex pattern
<kristianpaul>
like a knwo series of 4 nibbles or soemthing
<wpwrak>
how wide is you register interface to the receiver in the FPGA ? 8 bits ?
<kristianpaul>
8 bits
<kristianpaul>
but thats for the acquisition core
<kristianpaul>
right now two bits no more i need for namuru,sign and mag no more
<kristianpaul>
clk, sure :)
<wpwrak>
ah, so you're not working on the acquisition core anymore ?
<kristianpaul>
i already said, i stoped offline processing
<kristianpaul>
i dont wanted to spend more time on it... because osgps will never correlate complex data
<wpwrak>
hmm. why ? :) that just seems to make things harder. any processing algorithm should be just as happy with a recorded bitstream as with a "live" bitstream
<wpwrak>
i mean
<wpwrak>
there's no feedback, so ...
<kristianpaul>
afaik the SoftGNSS code neither,, well i got a update version from fabrizzio but dint looked at it yet or planing soon
<kristianpaul>
sure sure, but i wanted to speed up
<kristianpaul>
i took me, long time to learn m1 internals (wishbone, verilog conding, HDl, RTl...)
<kristianpaul>
then some C,
<kristianpaul>
then retake gps theory and try to understand..
<wpwrak>
sure :) but it seems that you just made the problem more difficult, by adding a throughput constraint
<kristianpaul>
then realize my previos mistakes
<kristianpaul>
throughput constraint?
<wpwrak>
well, or replacing an "easy" throughput constraint with a harder one
<kristianpaul>
dont get it..
<wpwrak>
(throughput constraint) that you have to be able to process the data in real time
<kristianpaul>
ah you mean because i shifted the data?
<kristianpaul>
ah, yes but when i was told of namuru i had very empties about gnss and dsp
<kristianpaul>
now i dont, well no soo much :)
<wolfspraul>
qwebirc83241: hi there
<wpwrak>
i don't understand how namuru vs. ogpsd would affect the choice between offline/real time
<wpwrak>
i picture the architecture of any such thingy as follows:
<kristianpaul>
qwebirc83241: hi :)
<wpwrak>
1) there's some interface that picks up the data
<kristianpaul>
Artyom perhaps? :-)
<wpwrak>
2) there's some digital filtering and such
<wpwrak>
3) there's correlation and such
<wpwrak>
4) there's calculation of the position
<wpwrak>
5) there's some form of output
<wpwrak>
maybe i skipped a few intermediate steps
<wpwrak>
so it would seem that the difference between real-time processing and offline processing would be mainly in step 1 and maybe step 5
<kristianpaul>
it depends
<wpwrak>
is this correct ?
<kristianpaul>
yes
<kristianpaul>
well,
<kristianpaul>
you can do soft correlation (all osgps )or hard correlation (namuru + osgps)
<wpwrak>
so you're porting the baseband processor of namuru to the M1 ?
<kristianpaul>
it is ported, now i dealing with things dint work as spected :)
<wpwrak>
i see. okay, that explains why you're still fighting with clock domains and such :)
<kristianpaul>
well, that already was managed
<wpwrak>
how do you know before you see it work ? ;)
<kristianpaul>
hehe dont make mee doubt again
<kristianpaul>
:)
<wpwrak>
*grin*
<kristianpaul>
he, is okay, at least this time i lear from you and did a small test program that read and write a  namuru control register
<wpwrak>
that's or course one of the problems here - very few intermediate points where you can check things. what might help is a reference bitstream from an RF frontend (or some synthesized bitstream). if you had that, you could feed it into your system and compare the results.
<kristianpaul>
but afaik spartan6 popup some other issue with routing clocks, and i have to asume that for now and do a workaround
<wpwrak>
i wonder if the namuru guys don't have such a reference data stream. it would make testing a lot easier than just trying to use live signals every time
<kristianpaul>
i could ask, Peter Mumford sounded friendly last time i asked to him.
<wpwrak>
maybe you could just ask how they debug all their stuff. maybe all they do is really just plug it an antenna and see what happens. but maybe they have some test data sets with know inputs and known outputs.
<kristianpaul>
atenna, yes thats the most likelly i think
<kristianpaul>
ah, yes there was a ugly truought limitation with mm1, for the ethernet part,
<kristianpaul>
even in complex mode, too much data to transmit and no enogutht bandwicth.. and of course no way to decimate
<wpwrak>
hmm, how much data does the sige generate ? 8 Mbps ?
<wpwrak>
and how long do you need to receive before the algorithm can "see" something ? 30 seconds ? more ?
<wolfspraul>
I think it can theoretically be many minutes, curious what kristianpaul says...
<wolfspraul>
I believe he has already downloaded some start/static data to help the algorithm speed up, that was my understanding at least. maybe incomplete or wrong understanding.
<wpwrak>
wolfspraul: you mean the almanac ?
<wolfspraul>
yes, maybe that, not sure
<kristianpaul>
wpwrak: in complex mode 2.048MSPS (4 bit sample), real mode 16.384MSPS (2bit sample)
<kristianpaul>
wpwrak: remenber gps telemtry is 50bps
<kristianpaul>
sure you can cheat and get a fresh almanac and load to osgps, also give a warm position, so things can speed up
<wpwrak>
s/cheat/optimize/ ;-)
<kristianpaul>
sure,
<kristianpaul>
and yes, every 30seconds you get a frame if remenber well
<wpwrak>
have you successfully decoded an entire navigation message yet ?
<kristianpaul>
NO
<kristianpaul>
:-)
<wpwrak>
ah, no need for an almanac then :)
<kristianpaul>
no yet
<kristianpaul>
i confir signal, but wasnt able to track it..
<wpwrak>
30 s per frame .. so that's a minute to be sure you get at least one, no matter when you start (in relation to the atomic half-second)
<kristianpaul>
of course at leat in 12 seconds or less no 6, you can get a TLM
<wpwrak>
with real data, that's 4 MBytes * 60 = 256 MB. hmm. can M1 store to uSD ?
<kristianpaul>
NO
<kristianpaul>
:(
<wpwrak>
with complex data it would only be 60 MB ...
<kristianpaul>
i created a ramdisk in rtems for data
<kristianpaul>
but afaik all samples i have are complex
<wpwrak>
and you can't arithmetically convert complex to real ?
<kristianpaul>
i dont know how but in therory yes,
<kristianpaul>
but is not worth
<wpwrak>
like in  r = hypot(q, i);
<kristianpaul>
every complex sample is 4x a real one
<kristianpaul>
i undertand
<wpwrak>
well, you would have a lot less data, it seems
<wpwrak>
(TLM in 6-12 seconds) but only if you're synchronized with the atomic clock, right ? otherwise you still need to receive for maybe 40 seconds, correct ? (i.e., if you begin receiving just after the first bit of a TLM, then you need to keep receiving until the next message, plus the time until the end of that message's TLM.)
<wpwrak>
so just looking for TLMs only helps if you want to make many acquisitions and try your luck. but not if you want to be sure that the data you're looking for must be the acquisition.
<kristianpaul>
every subframe (6s each) have a 8 bits preable so you can catch that and sync the rest from there
<wpwrak>
aah, i see
<wpwrak>
and you've received and decoded subframes yet ?
<kristianpaul>
no, as i said just detected signal,
<kristianpaul>
but i'm working on it
<wpwrak>
(TLM) ah, i see that there's more than one in a message. that helps.
<kristianpaul>
once the accumlator works, i can do a loop that will slew the code nco until get a interesting treshold
<kristianpaul>
of course this loop isnt aware of dopler.. and a moving satellit,
<kristianpaul>
so thats whena  "pull-in" algorthm saves the day :)
<wpwrak>
pick a satellite on a tangential course ;-)
<kristianpaul>
sure i can
<kristianpaul>
gpredict tell me
<wpwrak>
or maybe one that's stopped for maintenance :-))
<kristianpaul>
lol
<kristianpaul>
you need  that subframe before now satelly health..
<kristianpaul>
s/now/know
<kristianpaul>
that could be donne in india,i think their gnss implementation dont move so much...
<wpwrak>
(gpredict) nice :)
<kristianpaul>
gpredict plus a fucunbe dongle is great, you can get weather telemtry, listen ISS.. and what not
<wpwrak>
aah, that's what you want the funcube for !
<kristianpaul>
yeah, i need an updated forecast :)
<kristianpaul>
also listen some cubesatswith open telemetry
<kristianpaul>
even a coming artist related sat, (sat.mur.at)
<kristianpaul>
and my prefered FM station ;)
<wpwrak>
hmm, no GPS satellites over the south pole. that's about the worst place to have your GPS fail :)
<kristianpaul>
hah
<wpwrak>
hmm, gpredict seems to lack a nice trajectory view. e.g., something like the trajectory for the next hour
<wpwrak>
and it's hard to get rid of the ground area
<kristianpaul>
you can modify time
<kristianpaul>
buy yeah, there are some shortcomings for prediction..
<wpwrak>
tuxbrain: (cad) that is ... maybe i do have a solution for the extrusion problem that's not too hard to implement ... hacking ...
<kristianpaul>
zz
<wpwrak>
kristianpaul: caffeine !
<kristianpaul>
wpwrak: tea dint worked well...
<Artyom>
Is anyone here? ;)
<kristianpaul>
hi Artyom
<kristianpaul>
nice to see you around :)
<Artyom>
hi KristianPaul :)
<Artyom>
thank you. I've seen your discussion here couple of hours ago - very interesting ;)
<kristianpaul>
ah,yes wpwrak always made good questions :)
<Artyom>
I face very similar problems with debugging hardware...
<ignatius_>
Hi, all. Finally solved the boot up issue. I figured out why. Apparently, I needed to wipe the NAND clean and reinstall everything. Which I was trying to avoid. Oh well. No, I have a new problem; the rootfs doesn't use the entire NAND space... there are about 4 seperate "tmpfs" entries, each using about 40MiBs.. So, my question is, how do I get the system to use all of the space in the rootfs?
<kristianpaul>
btw, before i fogot what's the license of gps_for_www.zip ?
<kristianpaul>
Artyom: how you sort it out?
<Artyom>
Good questions. My aim was to make a free project in order to attract people to it. I didn't put any information about license because I don't know much about it. May be you can suggest something?
<kristianpaul>
dual lincense GLPv3 and CC-BY-ShareAlike version 3.0 :)
<Artyom>
And how it can be done? I only have to add a text file with license to the source?
<kristianpaul>
yeah, a file called LICENSE should be okay for thre PCB design i think..
<wpwrak>
(this one has GPL v2+, LGPL v2.1+ and CC-BY-SA 3.0)
<Artyom>
thanks for this example :)
<kristianpaul>
so many questions, also i'm curious about your work around osgps, and the fpga-arm board..
<wpwrak>
Artyom: regarding testing, so how do you test/debug ? just plug in an antenna and start receiving ? or do you have some reference data that you've recorded/generated and that you can replay ?
<Artyom>
With namuru I wrote some hdl-test at first. And I fed signal from the file in this test. This way I checked the acquisition process.
<Artyom>
But it is very slow
<Artyom>
For traking I tried to work with real signal from antenna
<Artyom>
But with no success for now
<wpwrak>
the test with the file would be in a simulator ?
<Artyom>
But I used my own code for tracking wich I checked in matlab/scilab with Akos code
<Artyom>
Test file was made with my hardware (gnss-sdr front-end)
<Artyom>
And I processed this file with matlab/scilab code to find out which satellite are in view (and to know doppler)
<Artyom>
But
<Artyom>
tracking doesn't work now
<Artyom>
Sorry, I have to leave now. I will join this chunnel as soon as I will come back to my pc. I will definitly try to answer on all questions.
<wolfspraul>
zedstar: did sujan publish any blog post about the nepal trip?
<kristianpaul>
oh, i dint knew tha tracking dint worked...
<kristianpaul>
or he meant that for the simulated data?
<kristianpaul>
wolfspraul: nice choice from ME cartoon :-)
<wolfspraul>
yes
<wolfspraul>
tomorrow is 08-01
<wolfspraul>
I am so totally behind again
<wolfspraul>
cleanup more tomorrow...
<kristianpaul>
ok. i'll try to cleanup what i wrote there then
<wolfspraul>
he :-) thanks!
<wolfspraul>
but no worries I'll go through...
<kristianpaul>
great, no worried now then :)
<wpwrak>
wolfspraul: hmm, no word about atben/atusb production finishing and them being available now ? june only had the pcbs, no smt/testing/shop yet
<wpwrak>
milkymist news: rc3 boards have been made and are being tested
<wpwrak>
milkymist: maybe also point to all the "paperwork" - leaflet, flyer, box ?
<kristianpaul>
wpwrak: please edit the wiki
<kristianpaul>
openwrt is nice to quoute indeed
<wpwrak>
(edit) naw, i think it's better for consistency if things pass through the editor. if i just dump things there, it's probably harder to find them. also, it may be more awkward to remove items considered irrelevant
<wpwrak>
kristianpaul: removal is tricky. you're undoing work someone else has spent time on. sometimes worse, you may not like where an emphasis is put but it may be hard to change that.
<kristianpaul>
tuxbrain: also offered some stuff for people interested to work in arduino support for atben
<kristianpaul>
dunno if he want such us publicity?
<wpwrak>
i don't remember seeing that
<kristianpaul>
9382:257489:16:33 < tuxbrain> talking about arduino modules: who was here interested/skilled to develop an Arduino version of the atben/atusb? also DocScrutinizer you were almost skilled in rf , how about bost mA of emision on the atben/atusb?
<wpwrak>
ah, that may have been a reference to [g2] whom i mentioned to tuxbrain earlier. [g2] was planning to make an arduino with built-in ieee 802.15.4. haven't heard from him for a while, though.
<roh>
it draws the bars by using the lcd lib and these predefined special chars
<kristianpaul>
not wat i was looking for, for i ditn knew it of this putchar() xD
<wpwrak>
grmbl. meshlab is really trying my patience ...
<kristianpaul>
okay the carrier NCO is getting stuck.. why?..
<wolfspraul>
roh: thanks for the heads up about picture! yes, that's the nicest of the 4, you are right. Will mention it.
<Jay7>
thought about CF-6lowpan
<Jay7>
may be useful for CF-only devices
<Jay7>
e.g. for zauruses which have no wireless ifaces (except SL-6000l/w)
<wpwrak>
Jay7: yes, you could make that. why not. CF isn't very popular these days anymore, so it's probably not something you could sell much, but you may make friends in the zaurus community :)
<kristianpaul>
hi Artyom
<Artyom>
hi Kristieanpaul :)
<kristianpaul>
16:04 here
<Artyom>
Sorry that I have to leave very soon last time
<kristianpaul>
np, actually i got sleep at that time :)
<Artyom>
I read that you faced similar problems with debugging osgps+namuru
<kristianpaul>
well, currently  the carrier nco is not working..
<kristianpaul>
but yes with osgps itseld i wasnt able to track signal
<Artyom>
In my case I think that the problem is in interface between arm7 and fpga.
<kristianpaul>
wich fpga are you using?
<Artyom>
Thay are connected through a async static memory interface
<kristianpaul>
bur currently i'm working all in the FPGA
<kristianpaul>
but this async interface still preserver namuru memory map?
<Artyom>
no, I had to change memory map because of memory addressing...
<kristianpaul>
what about in osgps?
<Artyom>
I tried to use only single chanel in FPGA.
<kristianpaul>
same here :)
<Artyom>
about osgps: i slowly studing the code. I made it work with file that I wrote with my front-end. And I received a PVT-solution
<Artyom>
Now I want to split osgps in two parts. One (the correlator part) will work on pc and the second part will work on ARM. This way I want to debug ARM code and then I will focus on FPGA-correlator
<kristianpaul>
is not that similar to what is gpl-gps?
<kristianpaul>
well, i dint check that code but i read the thesis
<kristianpaul>
wow, PC <-> arm <-> fpga, sounds line a lot of fun :-)
<kristianpaul>
alas, will be nice have a portable gps receive, dont you think?
<kristianpaul>
or what is you final aplication?
<Artyom>
Actually at first I wanted to use gpl-gps+namuru. But later Iater I switched to gpl-gps because it continued to develope and because there is a full-software solution.
<kristianpaul>
is this gps work fo you related to some University, or something on your own?
<kristianpaul>
the lately aboyt fpga+arm
<Artyom>
I would say both. There are some potential applications in the university (some works connected with pseudolites). But everything have started as my own initiative...
<kristianpaul>
nice :-)
<kristianpaul>
and you have a repository or something to follow your commits?
<Artyom>
no, right now only some source on my pc. No time to spend on studing svn or git :(
<kristianpaul>
he, sure :)
<Artyom>
And what is your aim? ;)
<kristianpaul>
portable receiver as well
<kristianpaul>
i'm currently using milkymist board as i told you in last mail i think
<kristianpaul>
milkymist one*
<kristianpaul>
is not that portable but the idea once work is make it portable  of course :)
<kristianpaul>
or may be a combo with a mips cpu
<kristianpaul>
but first it need to work :)
<kristianpaul>
btw how do you replaced the lpm_counters from the time_base core?
<kristianpaul>
with another xilinx library or own hdl code?
<Artyom>
hdl-code
<kristianpaul>
this is odd, tic_enable and pre_tic_enable seems working
<Artyom>
for all altera-specific functions
<kristianpaul>
but my carrier NCO is stuck on same value 16282106
<Artyom>
and how do use osgps on milkmist? Do you have a soft-cpu on spartan?
<kristianpaul>
yes
<kristianpaul>
lm32
<Artyom>
how do you check it (NCO)?
<kristianpaul>
lattice mico32, a BSD-like licensend CPU
<kristianpaul>
i was reading CODE_MEASUREMENT register
<kristianpaul>
so i do same with CARRIER
<kristianpaul>
so now i'm checking 10 msb bit from acum_reg register in the scope
<Artyom>
and did you check carrier-nco output on scope?
<kristianpaul>
i'm on that righ now
<kristianpaul>
as reading the register gave me same value...
<kristianpaul>
and yes it can run uclinux and rtems
<Artyom>
looks very complicated for me ;)
<kristianpaul>
;-)
<kristianpaul>
so as osgps is ansi C will be easy to port, but right now i'm doing some basic tests in software, at least a loop with the code slew and see what i catch
<kristianpaul>
but that will be after i get carrier nco to work..
<Artyom>
yes, I decided that it's better to use language that I know a little then to spend time on studying new language...
<kristianpaul>
how do you debug namuru? just reading control registers and such or?
<Artyom>
I wrote simple test for each vhdl-file to be sure that it works correctly.
<kristianpaul>
ah, testbench i see
<Artyom>
yes
<Artyom>
After that I wrote a simple test for full-corelator. This test read data from a file with GPS-signal-record and put data to namuru input. It also made some initialisation (like setting tic-period and all the rest). Also prn number was chosen and doppler set to correct value. And finaly
<Artyom>
I passed through all delays
<Artyom>
The result was written to the file. And I made a graph and saw that there was a correlation peak
<Artyom>
After that I started to experiment with hardware
<Artyom>
how can I show you my code for time_base?
<Artyom>
Oh, I've seen it and I would like to play with it in the future. But now I don't know a lot about it. How to use it. And what kind of receiver do I need to play with it