Topic for #qi-hardware is now Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs
jekhor [jekhor!~jek@mx2.promwad.com] has joined #qi-hardware
zedstar [zedstar!~john@fsf/member/zedstar] has joined #qi-hardware
Textmode [Textmode!~boneidle@adsl-syd-2-209.ozonline.com.au] has joined #qi-hardware
steve|m [steve|m!~steve@osmocom/steve-m] has joined #qi-hardware
steve|m [steve|m!~steve@osmocom/steve-m] has quit [#qi-hardware]
steve|m [steve|m!~steve@osmocom/steve-m] has joined #qi-hardware
mstevens [mstevens!~mstevens@fsf/member/pdpc.active.mstevens] has joined #qi-hardware
jekhor [jekhor!~jek@mx2.promwad.com] has joined #qi-hardware
Ornoterm1s [Ornoterm1s!~rikard@78-69-248-123-no180.tbcn.telia.com] has joined #qi-hardware
antoniodariush [antoniodariush!~antonioda@nat-sta-smtc2.tvu.ac.uk] has joined #qi-hardware
antoniodariush [antoniodariush!~antonioda@nat-sta-smtc2.tvu.ac.uk] has joined #qi-hardware
paroneay` [paroneay`!~user@c-67-175-218-235.hsd1.il.comcast.net] has joined #qi-hardware
Ayla [Ayla!~paul@178.53.192.77.rev.sfr.net] has joined #qi-hardware
antoniodariush [antoniodariush!~antonioda@nat-sta-smtc2.tvu.ac.uk] has joined #qi-hardware
wolfspraul [wolfspraul!~wolfsprau@p5B0AB3BE.dip.t-dialin.net] has joined #qi-hardware
paroneayea [paroneayea!~user@fsf/member/paroneayea] has joined #qi-hardware
kuribas [kuribas!~user@d54C43316.access.telenet.be] has joined #qi-hardware
antgreen [antgreen!~user@70.50.65.59] has joined #qi-hardware
jluis [jluis!~jpddb@83.247.136.72] has joined #qi-hardware
emeb [emeb!~ericb@ip72-223-81-94.ph.ph.cox.net] has joined #qi-hardware
antoniodariush [antoniodariush!~antonioda@nat-sta-smtc2.tvu.ac.uk] has joined #qi-hardware
antoniodariush [antoniodariush!~antonioda@nat-sta-smtc2.tvu.ac.uk] has joined #qi-hardware
wej [wej!~j@m2.mullvad.net] has joined #qi-hardware
urandom__ [urandom__!~user@ip-88-152-208-240.unitymediagroup.de] has joined #qi-hardware
mth [mth!moszdyzk@c74072.upc-c.chello.nl] has joined #qi-hardware
<wpwrak>
happiness is ... a new monitor, with working backlight :)
<viric>
when the lack of monitor is your biggest problem :)
wej [wej!~j@m2.mullvad.net] has joined #qi-hardware
<wpwrak>
maybe not the biggest but a rather annoying one. well, i should buy some food, too. or else, i'll complain about something else before too long :)
Ornotermes [Ornotermes!~rikard@78-69-248-123-no180.tbcn.telia.com] has joined #qi-hardware
kilae [kilae!~chatzilla@catv-161-018.tbwil.ch] has joined #qi-hardware
jekhor [jekhor!~jek@vulture-nat-32.telecom.by] has joined #qi-hardware
Artyom [Artyom!~chatzilla@84.23.62.191] has joined #qi-hardware
<Artyom>
kristianpaul hello
<kristianpaul>
Artyom: hi !
<Artyom>
kristianpaul: I've thought a little about plans for the neasrest future touching osgps. If you are interested we can discuss them...
<kristianpaul>
go ahead
<Artyom>
Nearest plans include: 1. Testing software with signal from sattelite (not from imitator).
<Artyom>
2. Replacing magic numbers by variables that must be calculated at program start
<Artyom>
3. Making simple signal generator in verilog. Actually this is just a simplified version of correlator channel that includes only carrier_nco, code_nco, code_gen and their control registers. (For example, original gp2015-correlator allows to use one of the channels for this purpose.)
<Artyom>
4. After this correlator channel can be tested in software without need of special signal-simulator or active_gps_antenna.
<Artyom>
5. Making two channel version (I'm afraid that more channels will not fit in FPGA that I use).
<Artyom>
That's it. What do you think?
<kristianpaul>
About 1. So this testing should be included in osgps? like a menu ask you to confirm signal acquisition from one satellite your know is in the skyview?
<kristianpaul>
About 3. Looks nice too, i'll check this on gp2015 datasheet
<kristianpaul>
About 2. wich variables you mean?
<kristianpaul>
ABout 5. yeah two is a safe numer to grown more channels later :)
<kristianpaul>
and later you may consider a bigger fpga (like the one in M1) to implement 12 correlators :)
<Artyom>
1. I keep in mind not exactly osgps port, but a simplified version which I use. (The idea to select a satellite at start is fine :))
<kristianpaul>
sure
Artyom_ [Artyom_!~chatzilla@84.23.62.191] has joined #qi-hardware
<Artyom_>
2. I mean such values as carrier_nco control word, code_nco_control word, accum_int_periode control word and the reset which depend on the clock frequency that we use.
<Artyom_>
5. Yeah, later I will definitly use something more suitable for MM SoC ;)
<kristianpaul>
ah, gotach you mean detect clock frequency, i like this so we can work with sige and maxim chips and may be others later
<lindi->
just a quick note, are you all subscribed to foss-gps list?
<kristianpaul>
i di
<kristianpaul>
s7di/do
<kristianpaul>
lindi-: but very much talk about rtklib no else... since i suscribed tought
<kristianpaul>
s/di/do
<qi-bot>
kristianpaul meant: "lindo-: but very much talk about rtklib no else... since i suscribed tought "
<kristianpaul>
argh
<kristianpaul>
dam bot
<lindi->
kristianpaul: exactly, you could post about your fpga ideas
<lindi->
or Artyom_'s, I haven't yet read all scrollback
<kristianpaul>
yes please there is plenty of logs in this channel about it :)
<Artyom>
I'm not sure that "to detect", but to set during compilation or something similar seems attractive
<Artyom>
kristianpaul: RTOS should be used anyway. RTEMS ssems attractive, but I didn't think a lot about it. May be some other RTOS, may be RTEMS. BTW Did you experiment with RTEMS?
<kristianpaul>
Artyom: RTEMS well yes, at least to make it work
<lindi->
kristianpaul: ok, that seems to have last modified set to "2001", is this true?
<kristianpaul>
lindi-: website yes, code have commitns some months old
<lindi->
kristianpaul: does this osgps program have a git repository or something somewhere?
<kristianpaul>
Artyom: Michele Bavaro is on that list too
<Artyom>
Michele Bavaro ;) He mentioned my toy on his blog ;)
<kristianpaul>
lindi-: from osgps for _now_ we jsut need gpsrcvr.c to make it work on our milkymist soc that uses namuru correlator
<Artyom>
kristianpaul: you too? ;)
<kristianpaul>
dont think so, i havent even write it yet
<kristianpaul>
he replied to me once i wrote osgps list
<kristianpaul>
about using osgps implementation of gp2021 correlator
<lindi->
kristianpaul: ok but I guess rtklib could be used as an alternative too?
<kristianpaul>
s/it/him
<kristianpaul>
lindi-: please tell us how :-)
<lindi->
kristianpaul: if you can give me rinex from a single receiver I can calculate position easily
<kristianpaul>
i dint found it very well documented, and it seemed to me i just work with certain navigation data formats?
<lindi->
kristianpaul: I convert UBX to rinex using rtklib-convbin
<kristianpaul>
anyway we can *therically* provide that data, but no idea how rtklib could help from thre
<lindi->
kristianpaul: it works here :)
<lindi->
kristianpaul: so you don't have any raw data captured yet?
<kristianpaul>
if you mean raw I/Q data yes :)
<lindi->
ok
<kristianpaul>
lindi-: had you read about namuru correlator project?
<Artyom>
kristianpaul: you can process I/Q data with SoftOSGPS and have RINEX data as output ;)
<lindi->
kristianpaul: not much
<kristianpaul>
lindi-: can you point me an example where rtklib process a navigation message?
<kristianpaul>
Artyom: nope no :)
<lindi->
kristianpaul: yes
<Artyom>
kristianpaul: why not? ;)
<kristianpaul>
Artyom: i event havent look at nmea code yet
<kristianpaul>
Artyom: i wodner if this work
<kristianpaul>
Artyom: you can process I/Q data with SoftOSGPS and have NMEA as output? :)
<kristianpaul>
lindi-: please :)
<Artyom>
I played a little this way. I recorded I/Q data with my front-end and processed it with SoftOSGPS. I received a position fix :) May be I should write a note in my blog about it...
<kristianpaul>
ah yes, i tied that first
<lindi->
kristianpaul: pntpos() in src/pntpos.c is afaik the simplest mode
<Artyom>
Ohnestly speaking: I didn't check nmea or rinex output. But I could see on the screen my coordinates
<kristianpaul>
Artyom: never got the fix.. but at that moment i dint knew it osgps dint support complex processing :/
<kristianpaul>
well that told me cwkelley
<lindi->
I do have access to a software defined radio but unfortunately I don't think I have time to capture you any live GPS data since that'd require some tinkering with antennas and amplifiers if I understand correctly
<kristianpaul>
no problem
<kristianpaul>
idea here is do live processing,
<lindi->
rtklib can do live processing too
<lindi->
but I've always done everything offline
<kristianpaul>
yes sure, but not in a risc cpu running at 80Mhz :)
<kristianpaul>
or yes?
<kristianpaul>
thats why the fpga and the namuru thing :)
<lindi->
rtklib has been optimized to run on a beagleboard
<lindi->
which is 500 MHz (?) ARM
<Artyom>
rtklib is interesting if you want to play with (don't know how it is exactly named in english) relative positioning. When you want to know coordinates of one receiver relative to another. In this case you can find relative coordinates very preciously.
<kristianpaul>
and prcecislly i heard?
<kristianpaul>
i mean accurate
<lindi->
yep, I got around 10 cm precision
<Artyom>
With OSGPS you can determine your coordinates with 5-10 meters accuracy. And with rtklib, like lindi mentioned, up to 10 cm
<Artyom>
lindi: What are you working on? What is your project aims? ;)
<kristianpaul>
yes :)
<lindi->
Artyom: that was just a crazy hobby project that escalated accidentally
<lindi->
Artyom: I wanted to test rtklib and I had no raw data, at the same time I hated the fact that my openmoko ran non-free software to compute GPS position
<lindi->
Artyom: so after some reverse engineering of the GPS firmware I was able to solve both problems
<kristianpaul>
Artyom: btw for osgps wich raw I/Q format you used 16-bit I/Q interleaved? and how much sampled time?
<Artyom>
lindi: So you used ANTARES chipset as your gps-receiver? (It's something like popular sirf?). And what data was processed by rtklib (rinex, nmea something else)?
<kristianpaul>
i still want to record data, afaik i did wrong at the time i tried
* kristianpaul
feels bad about it
<Artyom>
kristianpaul: what kind of data do you want to record?
<lindi->
Artyom: yep openmoko has ublox antaris 4
<kristianpaul>
Artyom: the real out-put from my sige and your maxin board
<lindi->
Artyom: slide 22 has links to the raw data
<kristianpaul>
Artyom: when i recorded it was 4 bit I/Q interleaved, then i have to bloat to 16 bits, the process with osgps
<lindi->
Artyom: I asked the ublox chip to send me data in UBX format
<kristianpaul>
Artyom: but as i said this was before i realized osgps dint support real data
<kristianpaul>
Artyom: anwyay, jsut asking, that was 1 year ago.. i wasted too much time on it, then discover namuru and your blog ;)
<lindi->
Artyom: slide 22 also shows how UBX is converted to RINEX
<Artyom>
kristianpaul: osgps as I remember works with real signals, not with I/Q-samples. So you have two possibilities: if IF-frequency of your front-end is high enough and sampling frequency is also high, then you can just through away Q-samples. Or you can hack OSGPS to work with I/Q-data. It's not difficult to make multiplication of complex-numbers (this is what I plan to add to namuru) ;)
<kristianpaul>
Artyom: with namuru is simpler i guess u simplify the correlator arm to I or Q, well i tought..
<kristianpaul>
Artyom: (multiplication) indeed but no now, :)
<kristianpaul>
lindi-: yes osgps is not the most clean code, but i could bne ported to Milkymist SoC, ignore PCI, DOS and win stuff
<kristianpaul>
even softosgps :)
<Artyom>
lindi: ok, now I understand. And rtklib works mainly with RINEX?And you could archive decimeter-level accuracy with cheap reciever (working with L1 only band)?
<Artyom>
kristianpaul: in correlator I use all 6 arms (Ie, Ip, Il, Qe, Qp, Ql).
<kristianpaul>
lindi-: rtklib uses fft for live processing?
<kristianpaul>
ah wait, it does not support real data samples right?
<lindi->
kristianpaul: samples?
<lindi->
kristianpaul: UBX has just results of the correlation
<kristianpaul>
yes i forgot .)
<kristianpaul>
oh
<kristianpaul>
UBX looks interesting format then :)
<lindi->
see slide 12
<lindi->
:)
* kristianpaul
downloads pdf
<Artyom>
kristianpaul: rtklib works with output of a GPS-receiver. For example it can potentially worj with OSGPS.
<kristianpaul>
yes
krispaul [krispaul!~krispaul@2001:0:53aa:64c:2893:3a08:4163:121f] has joined #qi-hardware
<DocScrutinizer>
lindi-: this pdf of yours still is awesome (though somehow triggers a deja vu sensation halfway thru ;-D ) - why don't you use adhoc wlan for data transmission?
<krispaul>
argh, blackout it seems
<lindi->
DocScrutinizer: I just don't want to risk anything :)
<DocScrutinizer>
risk?
<DocScrutinizer>
non-free software on 4th CPU? ;-P
<kristianpaul>
lindi-: indeed, you can sell preconfigured openmoko with your soft, gps receiver with centimer accuracy are pretty expensive
<lindi->
of wlan dropping some packets and compromising the data somehow
<DocScrutinizer>
duh, and the CPU in bq27200 also in proprietary ;-)
<lindi->
doing these experiments wasn't exactly easy. I had to guard the receivers in a rather busy place to make sure nobody steals them :)
<lindi->
anyways, this project is currently stuck until I can get better antennas
<DocScrutinizer>
s/ in / is /
<qi-bot>
DocScrutinizer meant: "duh, and the CPU is bq27200 also is proprietary ;-)"
<DocScrutinizer>
meh
<kristianpaul>
Artyom: so.. you no rtems for now, you board dont have the port
<kristianpaul>
Artyom: but may be i can run some basic code
<kristianpaul>
if memory map is same..
<kristianpaul>
anyway, will work on 1. :)
<kristianpaul>
What about you?
<Artyom>
kristianpaul: For now I will play a little with bare-hardware. I will make tasks that I have mentioned and then i will try ti switch to RTOS. A good news is that a port that I use should work with RTEMS. I even have hello_world application. But I didn't test it yet. May be next month...
<kristianpaul>
ok
<Artyom>
And of course it will be greate if you will have some experience with RTEMS. Then we could progress faster as RTEMS will definitly slow down my work
<Artyom>
it;s time to sleep for me now...
<kristianpaul>
ok
<Artyom>
good night
<kristianpaul>
15:51 still here :)
<kristianpaul>
n8 !
<Artyom>
and 00:51 here ;)
<kristianpaul>
lindi-: do you know about Milkymist soc?
<kristianpaul>
and milkymist one?
<lindi->
nope
<kristianpaul>
I would like make clear to you what are we trying to do
<kristianpaul>
but you know what the nanonote is right?
<kristianpaul>
the pocker computer with the a single chip
<viric>
pocket!
<kristianpaul>
xburst etcc.
<kristianpaul>
pocket*
<kristianpaul>
sorry viric !
<viric>
:)
<kristianpaul>
lindi-: short words (taking words from your slides), we are implementing similar task that the ataris4 gps receiver from atmel does
<kristianpaul>
inside a fgpa
<kristianpaul>
mixing free hdl code from milkymist project, re-using work from namuru correlator (DSP part), and creating a firmware re-using osgps source code
<kristianpaul>
the later output will be either a NMEA out (or rinex.. etc..) and of course a position fix
<kristianpaul>
i dont know if you get this inresting or not, just wanted to tell, may be you want to tell same in the floss-gps list, i dont know if not having a devices that provide a fix is worth to mention in those lists :)
<kristianpaul>
s/those/this
<qi-bot>
kristianpaul meant: "i dont know if you get this inresting or not, just wanted to tell, may be you want to tell same in the floss-gps list, i dont know if not having a devices that provide a fix is worth to mention in this lists :)"
<lindi->
kristianpaul: you still need non-free compiler to build all the fpga stuff?
<kristianpaul>
sintheizer
<kristianpaul>
and yes
<kristianpaul>
but there are WIP alternatives like LLHDL
<kristianpaul>
synthesizer*
<DocScrutinizer>
kyak: skynet/guest4711 queried me "WHO THE FUCK ARE YOU?" :-D
<DocScrutinizer>
I honestly didn't know what to answer ;-)
wpwrak [wpwrak!~werner@94-163-231-201.fibertel.com.ar] has joined #qi-hardware
kristianpaul [kristianpaul!~kristianp@cl-498.udi-01.br.sixxs.net] has joined #qi-hardware
kristianpaul [kristianpaul!~kristianp@unaffiliated/kristianpaul] has joined #qi-hardware
<qi-bot>
[commit] Werner Almesberger: m1/ledravaganza/shine-through.fig: trim PCB layers for extra LED visibility (master) http://qi-hw.com/p/wernermisc/b13b4e8
wej [wej!~j@m2.mullvad.net] has joined #qi-hardware
wej [wej!~j@m2.mullvad.net] has joined #qi-hardware
<wpwrak>
wolfspraul: did you pick -DKICAD_TESTING_VERSION=ON or -DKICAD_STABLE_VERSION=ON ?