<erikkugel>
sorry, Just saw Gazelle being mentioned, they are great (and the prices they list are usually higher than what one might get on eBay), but they are only accepting packages from the US... :(
<viric>
maybe RMS has some words to say about those practices :)
<tuxbrain>
wpwrak: you there?
<tuxbrain>
I'm unable to make the arduino recieve the values I want to send, it's receives somthing  but for its behaviour seems that I'm only sending one value (0) and when de 3 bytes bufer is full (executing spio four times) the buffer is full and then reads it, but is full of 0 values, I have modified spio to have two params one the order , at this time is only one (0x01) and the second param a value , in this case it must make the led blink "value" times bu
<tuxbrain>
an the fact is that is arduino is recieving but seems that spiio is not sending the trhee bytes, (or maybe arduino not  reiciving them
<tuxbrain>
also this doesn't work directly in main:
<tuxbrain>
spi_begin();
<tuxbrain>
spi_send(atoi(argv[1]));
<tuxbrain>
spi_send(atoi(argv[2]));
<tuxbrain>
spi_send(0x00);
<tuxbrain>
spi_end();
<tuxbrain>
argh why for God shake  it's only sending a 0x00 each four time I execute the spiio!!!!?
<wpwrak>
good morning :)
<wolfspraul>
good morning
<wpwrak>
after-boot checklist: clean nose: check, anti-hayfever pill: check, LD200 of caffeine: ... getting it ...
<wpwrak>
caffein being administered. now to the backlog ...
<tuxbrain>
hahahahah, I was like you 3 days ago, happy flu wpwrak
<wpwrak>
tuxbrain: you had hay fever in late summer ? that's pretty unusual
<wpwrak>
i hope to be rid of the flus for this year. two different ones in as many months were quite sufficient. now it's just the pollen and then i can look forward to a beautiful untroubled summer :)
<tuxbrain>
yes all in shorts and I shivering and sweeting wonderfull
<wpwrak>
hmm, that sounds like a regular flu then. they suck too, of course. just differently :)
<wpwrak>
tuxbrain: first of all, do you still only get zeroes ? second, in which SPI mode is your arduino ? there are four of them, all mutually incompatible
<kristianpaul>
Artyom: if you have a trackign number i can try to rech postal office
<Artyom>
Yeh, I try to study svn. This is my attempt to use it for my projects.
<kristianpaul>
:-)
<kristianpaul>
i noticed, this tracking is offiline or scilab is just there for plot the results coming from namuru on the board?
<Artyom>
Well, it's difficult with tracking number. I think I'v lost it. I\ll try to find it but I'm not sure :( May be it was saved in browser cache when I used it...
<kristianpaul>
i also noticed negative values in the chart is this a know offset  to apply or?
<Artyom>
6 correlators (or may be better to say 6 summators) = 1 tracking channel (early, prompt, late for in-phase and quadrature channels)
<Artyom>
What do you mean by negative values?
<kristianpaul>
in the plot
<kristianpaul>
y goes from -4000 to 4000
<kristianpaul>
Artyom: on my side i got logginf correlators now, but just missing plot, wich i will use gnuplot i guess
<kristianpaul>
me not very good with scilab as i wish :)
<Artyom>
This is output from accumulators. No additional procesing in scilab was made. For example the similar graph is plotted here: http://gnss-sdr.ru/index.php?itemid=17 (upper right graph on the first figure)
<kristianpaul>
osgps, really looks different, i see lots of folders now
<Artyom>
many folders are specific for lpc2478
<Artyom>
main code is in isr-folder
<Artyom>
initialization code is in correlator.c
<kristianpaul>
yeah, checking correlator_init right now
<Artyom>
The code is far from ideal, but I hope it can be useful
<kristianpaul>
sure it is
<tuxbrain>
wpwrak: are you there? How I modify the Makefile to compile testMISO.c testMOSI.c .. etc? just additg its name to "all:"? separated by space or coma?
<tuxbrain>
kristianpaul maybe you also know this :P
<Artyom>
Ehm... you don't like value? or anything else? ;)
<kristianpaul>
i havent get the max in values in my side but i can notice value from ~400 to ~60000 right now
<kristianpaul>
s/in/min
<Artyom>
And what about negetive numbers?????
<kristianpaul>
good question :)
<Artyom>
what data type do you use?
<Artyom>
may be you use unsigned?
<Artyom>
Then 60000 is about -500?
<kristianpaul>
yes for now
<Artyom>
I think this is wrong. Signed number should be used. Otherwise phase/frequency/delay discriminators will not work IMHO
<kristianpaul>
yes
<wolfspraul>
kristianpaul: hah you were faster with the spam - thanks!
<kristianpaul>
ha, i just wake up a hr ago and read some news :)
<wolfspraul>
I've had a few cases some days ago
<wolfspraul>
Chinese spam, so easy because it's in my timezone :-)
<wolfspraul>
this one seems from elsewhere...
<kristianpaul>
Artyom: i must leave for hour and a half, but is great you realeased the code !!
<kristianpaul>
Now i'm behind :)
<kristianpaul>
Time to speed up
<kristianpaul>
Artyom: if you got that tracking # will be great, at least to know what happened with the letter, may be i need to go visit customs and explain what is a PCB ;)
<kristianpaul>
hope not
<Artyom>
I will also leave after half an hour. Yes, I'll try to find tracking#
<kristianpaul>
wolfspraul: may want to know a Artyom got to track a satellite, wich is great !
<tuxbrain>
I have communication SPI with arduino!!!!! yes yes yes
<tuxbrain>
dancing the happy geek dance arround the floor
<tuxbrain>
at last one way NN->arduino
<tuxbrain>
just two values but good.....  it feels soooo good
<wpwrak>
;-)))
<wpwrak>
where was the problem ?
<tuxbrain>
ehem ... mainly that I use the ICSP header that instead of nSEL has Rested (:shame)
<wpwrak>
;-)))
<tuxbrain>
wpwrak: only usleep(1) is needed to achieve comm between spi_begin() , spi_send(), etc, no need inside de spi_send fuction
<tuxbrain>
wpwrak: I have talked to quick, after a few test seems that some pause on spi_send function is needed but even putting usleep(1) makes the comm really slow about half a second or so pair of bytes (well really tree) there is any pause more quick than usleep?
<wpwrak>
tuxbrain: you can adds a small delay by just duplicating a setting. e.g., PDDATS = x; PDDATS = x; will add a small delay after rising "x".
<tuxbrain>
ok I will try
<tuxbrain>
ok the quickest I have achieved is as you said just repeating the PDDATS = x, and usleep(1) between calling fuctions , using serial at 115200bps it doesn loose any value for almost 5 mins so I give it as OK :)
<tuxbrain>
wpwrak: I have a couriose bug to catch now
<tuxbrain>
on the arduino side
<tuxbrain>
when I call the function flash_led() on the setup() fuction it respect the delay(whatever) I put in the for, but when I call it passing the parameter I put in the NN, it piss off on the delay, and goes as fast as it can
<tuxbrain>
I have put debug message to the serial output, and it does what it has too, it iterates the for the amount I said on NN, but...  it doen't respect the delay
<wpwrak>
where's the delay - on the arduino or on the ben ?
<tuxbrain>
on arduino
<tuxbrain>
ben does it's work, it pass the value and ends
<wpwrak>
do you use the delay function with delay(n*CONSTANT); or with for (i = 0; i != n; i++) delay(CONSTANT); ?
<tuxbrain>
void flash_led(int count)
<tuxbrain>
{
<tuxbrain>
  Serial.println("entro en la funcion flash_led");
<tuxbrain>
  Serial.print("count vale ");
<tuxbrain>
  Serial.println (count);
<tuxbrain>
  for (int i=0; i<count; i++) {
<tuxbrain>
    Serial.print("i vale ");
<tuxbrain>
    Serial.println (i);
<tuxbrain>
    digitalWrite(LED_PIN, HIGH);
<tuxbrain>
    delay(75);
<tuxbrain>
    digitalWrite(LED_PIN, LOW);
<tuxbrain>
    delay(75);
<tuxbrain>
  }
<tuxbrain>
}
<tuxbrain>
ups I should use pastebin
<wpwrak>
looks reasonable. and yes, you should ;-)
<wpwrak>
maybe the delay is too short ?
<tuxbrain>
the function flash_led() works when I call it on the setup() function , with a fixed value flash_led(4), to know is ready to accept nn instructions
<tuxbrain>
but totally ignores the delay  when I call it after the SPI comm
<wpwrak>
funny :)
<wpwrak>
this is converted by some pre-compiler into C, no ? then maybe check the C code for what it really does.
<tuxbrain>
yess really, the log in the serial looks just fine , it does al the iterations but the led blinks so quick it seems is just on for a instant , bigeer values make it bright longer it just ignore the delay
<wpwrak>
ah, wait a minute ... when you do, say, flash_led(10);, that works, right ? then you add SPI comm and do flash_led(received_byte); and it doesn't
<tuxbrain>
yes that's it
<wpwrak>
now, what happens if you do the SPI comm and follow it with flash_led(10); (i.e., hard-coded)
<tuxbrain>
same behaviour, it doesn't respect the delay but does the fixed iterations, (I have already tried)
<wpwrak>
hmm. so it appears tht the digitalWrite(LED_PIN, LOW); is being ignored ?
<tuxbrain>
no is the delay(75) due if it was the digitalWrite(LED_PIN, LOW) the led will should maintain bright after the iterations but it stays off
<wpwrak>
okay. check the generated code then. that looks like a translation bug.
<wpwrak>
or better, write it in regular C :)
<tuxbrain>
but there is no precompilation!, it just add the C headers and the calls to arduino libs is just text , there is not tranlation at all
<tuxbrain>
mmm well , tomorrow I will talk directly to David Cuartielles (Arduino Founder) and will expose that dilema
<wpwrak>
hehe, good ;-)
<wpwrak>
or maybe find a forum. this looks quite basic
<tuxbrain>
yes, is matter of lack of time before I meet David :P will be quicker also I have some meeting with Arduino Gurus, so we will find out, the NN part is ok (at least the NN->arduino) I have no more time to test Arduino ->NN or NN<->Arduino, I'm quite happy with the results, big big big thanks dude , I goonna make this Ardu loosers desire a NN as it was the fucking Sauron's Ring
<wpwrak>
very good. let's rule them ! ;-)))
<erikkugel>
lmao...
<tuxbrain>
moving servo with a Nanonote :) even cooler than the led
<wpwrak>
;-))
<wpwrak>
when will you release the skynet 0.1-alpha package ? :)
<tuxbrain>
Don't know but my version will not have the Connor bug :P, and of course will be realeased under GPL
<wpwrak>
aha ! under a viral license, so it spreads faster
<tuxbrain>
first release will be a lovely tuxbrain penguin able to build the next gen.... an even more lovely tuxbrain penguin, and thanks to this recursion as first law, I will not destroy humanity is a waste of brain and muscle, after some iterations, they will be so lovely that you will obey sayin , "I hate what I'm doing but they are sooooo cuuteee" BWAHAHAHAHAHAH
<tuxbrain>
time to sleep, I can move a servo with a Nanonote without need to solder anything to it... tired to do the happy geek dance but I'm going to bed humming the happy geek song
<wpwrak>
;-))
<tuxbrain>
three hours of sleep and  run to catch the fligh.
<tuxbrain>
see ya!
<tuxbrain>
whatever contact me by email
<Artyom>
Hi Kristianpaul :)
<kristianpaul>
Artyom: hello !
<Artyom>
I've found this number: RA112415246RU
<kristianpaul>
nice, i'll call postal company
<kristianpaul>
they said is not in the country yet
<kristianpaul>
Artyom: it was by postal/airmail right?
<Artyom>
It is written that 14.08.2011 it was exported
<kristianpaul>
yup
<kristianpaul>
well, know is in a unknow state until reach colombia
<kristianpaul>
but now i have # tracking number so i can verify with 4-72.com.co
<Artyom>
I don't know how it was sent. I know only that this type of sending was called "small package".
<kristianpaul>
delay is okay, i had ordered from india some seeds and took like two months to arrive
<kristianpaul>
Artyom: btw, about this tracking process, i'm little confused, let said i just want a namuru solution that provides telemtry, but then it will asume that i have to constantly feedback prn codes and no more?
<kristianpaul>
I mean for tracking do i need to know satellite ephemeris?
<Artyom>
I have the same experience with India ;) I sent letters from India to Russia and the delay was couple of months. (So Russia is like India ;) )
<kristianpaul>
or in theory just with and early, pront late correlator i can track a satelly over all sky?
<Artyom>
Ehm... let's go step by step about tracking.
<kristianpaul>
sure ;-)
<Artyom>
First of all: for acquisition and tracking you don't have to know anything about ephemeris or almanac.
<kristianpaul>
yes
<Artyom>
Every receiver has a "cold" mode. In this mode it has no information about ephemeris or almanac.
<Artyom>
So in this case you have to pass through all combination of delay/doppler_shift for each satellite
<kristianpaul>
yup
<Artyom>
When acquisition success for some combination delay/doppler_shift for some PRN (or some satellite in other words) then confirmation starts. If confirmation is also success then tracking starts to work
<Artyom>
During tracking you can take output from in-phase_promt correlator arm
<Artyom>
this I_prompt output is your navigation data (telemetry as you call it)
<Artyom>
The only thing that you must remember is that each bit lasts 20 ms or 20 I_prompt outputs
<Artyom>
so you have to make some additional steps to synchronize with 20ms-bits edges
<kristianpaul>
slew?
<Artyom>
You want to ask what to do with slew? Should we control it? Do I understand you right?
<kristianpaul>
yes
<kristianpaul>
I tought code slew was part of this bit synchronization, is it right?
<Artyom>
no ;)
<Artyom>
slew control is done only during acquisition
<kristianpaul>
ouch
<Artyom>
when tracking starts there is no need in additional slew control
<Artyom>
Everything is done by Delay Lock Loop which control chip-rate
<Artyom>
And the change in chip rate is equivalent to slew-control. But chip rate control is much more precious then slew control
<kristianpaul>
How do you change chip rate? is not suposed to be constant?
<Artyom>
No it's not constant ;)
<kristianpaul>
because doppler?
<Artyom>
i think - yes
<kristianpaul>
and then thats when the tracking loop plays its role?
<Artyom>
sorry... please explain this question...
<kristianpaul>
i mean,
<kristianpaul>
synchronize with 20ms-bits edges =Â Â change in chip rate ?
<kristianpaul>
and both are related _just_ with doppler?
<Artyom>
sorry once again :( Synchronize with 20ms bit edges != change in chip rate.
<kristianpaul>
hum ..
<kristianpaul>
not so i'm confused
<Artyom>
Let's forget for some time about data-bits... You can forget about them. Let's speak only about tracking.
<Artyom>
Tracking consists of two parts
<Artyom>
For simple receivers (like ours) these parts are independent
<Artyom>
One part of tracking is to follow carrier
<Artyom>
This is done by adjasting carrier_NCO_frequency
<Artyom>
We take output from correlator (two PROMPT outputs) and calculate the difference in frequency (or also phase) between our local NCO_carrier and the received signal
<Artyom>
According to this difference we calculate new frequency for carrier_nco
<Artyom>
Do you agree with this?
<kristianpaul>
yes, i think :)
<Artyom>
So this is how carrier tracking is working.
<Artyom>
We always have to control carrier because satellite is always moving with some acceleration so there is always some change in doppler
<Artyom>
And now the same explanation about code-tracking
<Artyom>
We have to track code because of the same reason: satellite is always moving!
<Artyom>
Because the change in chip rate due to doppler is very little for code-frequency (but it exists!) we have to control code position very preciously
<Artyom>
This precious control can not be done by slew rate (because slew allows us only to shit for half a chip - too much for our task)
<kristianpaul>
the code position is the same or related the edge of the bit you commented before?
<kristianpaul>
indeed half chip is too much
<Artyom>
you should not split "bit edges' and "chip rate"
<Artyom>
bits length depends on the current chip rate
<Artyom>
the idea of code tracking is absolutely the same as for carrier tracking
<Artyom>
the only difference is how to calculate difference between localy generated signal and satellite signal
<kristianpaul>
that difference is calculate by osgps right?
<kristianpaul>
if is true, is it fast enought?
<Artyom>
yes the difference is calculated by osgps
<Artyom>
yes it's fast
<kristianpaul>
i had seen your code mod_osgps a bit. at least is more clear than reading osgps with no folders ;)
<Artyom>
oh, thanks...
<Artyom>
I also changed many things. I tryied to make them simple and effective