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
jluis [jluis!~jluis@2001:5c0:1400:a::61d] has joined #qi-hardware
jluis [jluis!~jluis@2001:5c0:1400:a::61d] has joined #qi-hardware
jluis [jluis!~jluis@2001:5c0:1400:a::61d] has joined #qi-hardware
wej [wej!~j@m2.mullvad.net] has joined #qi-hardware
wej [wej!~j@m2.mullvad.net] has joined #qi-hardware
jluis [jluis!~jluis@2001:5c0:1400:a::61d] has joined #qi-hardware
<kyak>
i'll probably report it, so it won't get lost
jluis [jluis!~jluis@2001:5c0:1400:a::61d] has joined #qi-hardware
Artyom [Artyom!~chatzilla@84.23.62.191] has joined #qi-hardware
<Artyom>
kristianpaul hello
<kristianpaul>
Artyom: hi !
<Artyom>
Did you try to experiment with namuru? ;)
<kristianpaul>
working on it ;)
<Artyom>
ah, I see... :)
<kristianpaul>
i wanted to ask something
<kristianpaul>
some counters on the time base code, have a hardcoded reset value
<kristianpaul>
is this for some porpuse?
<kristianpaul>
i remenber initial value was 1111... or 0000... but not a constant
jluis [jluis!~jluis@2001:5c0:1400:a::61d] has joined #qi-hardware
<Artyom>
Now everythinh is like in native-namuru code...
<Artyom>
no such values
<kristianpaul>
hmm let me check again
<qi-bot>
[commit] Bas Wijnen: update things to work with new compiler and sdram chip (master) http://qi-hw.com/p/iris/538b9b9
<Artyom>
I used them for simulation purposes... Didn't want to wait for a long time when counter should go to zero-value
<kristianpaul>
ah :)
<kristianpaul>
btw you used the same variablenames for correlator from osgps?
<kristianpaul>
i was thinking to port osgps anyway, as it have yafss suport very important to save data
<mirko>
kyak: thanks, will test and then eventually commit it later
<kristianpaul>
btw what are you mid and long term plans with namuru and milkymist? may be we can define a devel tasks somwhere and make work to run faster?
<Artyom>
I don't remember exactly. But I think that I tried to use original code as much as I could. All the changes that I made - They are because I don't understand some features of the code. Or because it's done not optimal
<Artyom>
And what is yafss support?
<kristianpaul>
actually that code for the clear after read still scratching my head
<kristianpaul>
Artyom: well i mean a file system i can write/read
<kristianpaul>
so osgps can generate its logs and save ephemeris etc..
<kristianpaul>
just like it does on the PC
<Artyom>
I would like osgps to run with namuru. Milkymist seems to me resonable choise. So the idea to define a devel task and to make work run faster is very good.
<kristianpaul>
ok, what about to agree a place for that?
<kristianpaul>
or dicuss it or trought a mail in the qi-hardware mail list?
<kristianpaul>
or in the osgps mail list?
<kristianpaul>
whetever it is, that kept recorded is my concern
<kristianpaul>
(Milkymist seems to me resonable choise), i could not agree more :D
<kristianpaul>
i have this rought proposal before jump in to osgps and rtems:
<kristianpaul>
first make sure we have some basic rest procedures in the bios that gurantee the correlator works okay
<kristianpaul>
i dont know if waste of time, but i want avoid headache later with rtems and posible undiscover bugs
<kristianpaul>
s/rest/test
jluis [jluis!~jluis@2001:5c0:1400:a::61d] has joined #qi-hardware
<Artyom>
I think that you always have better ideas conserning organisation. So I would follow your suggestions.
<kristianpaul>
i also noticed some small HDL issues that may give headched, i need compare your with your port and confirm still there
<kristianpaul>
most because the mix of blocking and non-blocking asigments
<kristianpaul>
Artyom: btw you always test namuru with gps simulator?
<kristianpaul>
yes but i think you may have more idea for what to test/debug
<Artyom>
Yeah, there were some stange mixes in verilog code. I don't know verilog well, but xst complained on couple of code-lines though icarus-verilog simulating everything well.
<kristianpaul>
like the trehshols, correct early and late values.. dont know else right now
<kristianpaul>
well,more debug can be added later, but is good i think have it there in case you want confirm always all is good
<kristianpaul>
then i think move to rtems will be practical choice as most milkymist stuff is supported there
<kristianpaul>
but, that open the question that you should have a Milkymist One as well, i think of course you already give some feedback about limitations for your
<Artyom>
I always start experiments with simulator as the result is very predictable. But I test ARM+namuru code with real-signals too. I didn't have time to test MM port with real-sgnal yet. But very soon I will do it. But I think it should work.
<kristianpaul>
but i guess for doing all processing inside it, is okay
<kristianpaul>
yeap, i should work
<kristianpaul>
also i need to try your maxim receiver. and improve my soldering skill on the way :-)
<kristianpaul>
well, consideing most HDL part is already done and seems to work
<kristianpaul>
what miss is the fix, and what fits is osgps and perhaps more documentation about it
<kristianpaul>
or you think glp-gps is better starting poing?, they seems more oranized
<kristianpaul>
s/oranized/organized
<qi-bot>
kristianpaul meant: "or you think glp-gps is better starting poing?, they seems more organized"
<kristianpaul>
okay, i have a task before this Wednesday review and test last modiications of HDL and osgps mod on my board and sige receiver
<Artyom>
I keep in mind that it will be good to have milkymist one. But once again I will say "later"...
<kristianpaul>
ok
<kristianpaul>
I think you know more than me how to debug some namuru features, may be that can be write up somewhere?
<kristianpaul>
also i guess once that is settle, try to implement at least 3 correlators will be important (thats what i see a M1 usefull to you right now)
<Artyom>
I need some time to make couple of notes for my blog regarding latest advance with MM and namuru. And I have to write couple of articles for my work... That will pause me a little...
<kristianpaul>
I see
<kristianpaul>
No hurries either :)
<kristianpaul>
Artyom: do you like wikis?
<kristianpaul>
yes write take time well..
mth [mth!iptlhmhy@c74072.upc-c.chello.nl] has joined #qi-hardware
<kristianpaul>
damn i must leave i need cook lunch, but then feel free to add/comment what i said
<Artyom>
bon appetite! :)
emeb [emeb!~ericb@ip72-223-81-94.ph.ph.cox.net] has joined #qi-hardware
mstevens [mstevens!~mstevens@fsf/member/pdpc.active.mstevens] has joined #qi-hardware
jluis [jluis!~jluis@2001:5c0:1400:a::61d] has joined #qi-hardware
<Artyom>
I think that osgps is better choise because there is pc-port (softosgps). And it much more comfortable to debug code on PC than in hardware.
<Artyom>
Of course, softosgps differes a little from hardware. For example it doesn't emulate all delays that happen in hardware during calculating new control words and transmitting their values to correlator through wishbone-bus... I've heard that these effects are negligable but I didn't find a way how to check it.
<Artyom>
Yeah, my next step is implementing several correlator-channels. At least 4 are required in order to calculate a position. So I very hope that I could insert 4 channels+MM SoC in s3e500
zear [zear!~zear@2001:0:5ef5:79fd:1c5d:c6f:2abe:b43b] has joined #qi-hardware
<Artyom>
wikis are good thing :) If you have any suggestions where to write - just give me a link.
jluis [jluis!~jluis@2001:5c0:1400:a::61d] has joined #qi-hardware