2011-07-31 00:14 Artyom G around? 2011-07-31 00:16 wpwrak: writing manuals? 2011-07-31 00:17 oh man i want a funcube dongle http://www.oz9aec.net/index.php/gnu-radio/gqrx-sdr :-) 2011-07-31 00:18 plus a wearable antenna, all done ;-) 2011-07-31 00:21 ha, long mail :) 2011-07-31 00:22 yeah, SigE is very good writing shor datashetets ;) 2011-07-31 02:46 rjeffries_: which manufacturer sells a 1ghz arm for < 5 usd ? 2011-07-31 02:46 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 2011-07-31 02:47 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 2011-07-31 02:47 in low volume, it may easily be 30 USD and more 2011-07-31 02:47 looking at Freescale ARM right now, for example 2011-07-31 02:49 none of the 800 mhz or 1 ghz variants are in stock, phew 2011-07-31 02:51 here's one, 800 mhz. http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=MCIMX503CVM8B-ND 2011-07-31 02:52 USD 23.22 if you buy one, going down to USD 18.28 if you buy 100 2011-07-31 02:52 my number of 15-20 USD for a 1 ghz arm was probably a bit low, for our quantities 2011-07-31 02:54 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. 2011-07-31 02:55 let me know what you have in mind for 5 USD :-) 2011-07-31 03:00 oh wow, I rarely look at ARM prices, but I am so surprised how expensive the TI OMAP are 2011-07-31 03:01 40-70 USD at digikey, even for the 500-600 mhz range 2011-07-31 03:02 no wonder mediatek and now spreadtrum are taking the market from the bottom 2011-07-31 03:02 I get two full Android smartphones for the price of one TI OMAP chip :-) (exaggerating, but it gets close) 2011-07-31 03:48 two for the price of one, nice ;-) 2011-07-31 04:26 kristianpaul: (short data sheet) well, to be honest, some of sige's material is more like an insult than a data sheet :) consider this page: http://www.skyworksinc.com/Products_SiGe_Smart_Energy.aspx 2011-07-31 04:28 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 ? 2011-07-31 04:32 wpwrak: I think there's a trend to go closed. What do you think? 2011-07-31 04:33 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. 2011-07-31 04:33 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 :-) 2011-07-31 04:33 eventually we'll have that progress, then I see whether my email contacts still work there and still want to meet :-) 2011-07-31 04:34 after that I know more about SiGe's IP and datasheet policy/strategy/etc 2011-07-31 04:34 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. 2011-07-31 04:34 yes, I would agree 2011-07-31 04:35 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) 2011-07-31 04:36 new semiconductor startups are almost always very closed I found 2011-07-31 04:36 yes, they have too much to fear :) 2011-07-31 04:36 once you get to the level of passive components or other 'low level' semiconductors, it's mostly open 2011-07-31 04:36 not enough money to hire mercenaries ;-) 2011-07-31 04:37 once you move into anything baseband/rf, it gets very closed again 2011-07-31 04:37 it's like the baseband lives in a parallel reality or something 2011-07-31 04:37 yup, complexity is a factor 2011-07-31 04:37 no it's not just C code running in a core, it's 'magic' 2011-07-31 04:37 ;-) 2011-07-31 04:38 so much fuss about basebands and dsp, really 2011-07-31 04:38 mostly closed, I'm constantly looking for more documentation on such chips, but hard to find 2011-07-31 04:38 well, there's an active patent war in that area, so ... 2011-07-31 04:38 particularly as you move up to the higher performance items 2011-07-31 04:39 CMOS image sensors, also very bad 2011-07-31 04:40 maybe the same for those radar chips Sebastien is talking about sometimes? 2011-07-31 04:41 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 2011-07-31 04:41 the problem is that the judgment is so subjective 2011-07-31 04:42 heh, that could be a nice "map" 2011-07-31 04:42 (judgement) you the company's judgment whether to be open or close, or ours whether they are ? 2011-07-31 04:44 ours whether they are 2011-07-31 04:45 actually your mail, as so many times, set a good standard 2011-07-31 04:45 make the 'grading' of open datasheets measurable 2011-07-31 04:45 so it's not a matter of a marketing department deciding to declare the company's datasheets 'open' 2011-07-31 04:45 or the matter of a fan of a particular company or technology to declare the datasheets of that company to be 'the best' 2011-07-31 04:46 instead, you try to break it down to provable little factlets 2011-07-31 04:46 in the end it's all about electrons and physical phenomena 2011-07-31 04:47 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. 2011-07-31 04:47 one set of corner cases would be simply bad documentation, where you can't decode what it's actually meant to say 2011-07-31 04:49 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 2011-07-31 04:50 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) 2011-07-31 04:51 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 2011-07-31 04:53 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. 2011-07-31 04:54 once you have software running in a chip, the degree to which it is documented is harder to assess 2011-07-31 04:54 you can't just look at pins then, and make sure the electronic parameters are fully documented 2011-07-31 04:56 yeah. even if software just talks to the chip 2011-07-31 04:57 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 2011-07-31 04:57 that's when R&D turns into trial and error :) 2011-07-31 04:58 no I think you underestimate the degree to which the documentation level is part of a carefully orchestrated business plan and model 2011-07-31 04:58 managers are not that stupid 2011-07-31 04:58 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 2011-07-31 04:58 because they are only making chips, after all... 2011-07-31 04:59 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? 2011-07-31 04:59 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 2011-07-31 05:00 it's not an oversight, or a lazy or not so lazy engineer deciding how much he 'likes' to write 2011-07-31 05:00 I don't believe that. It's typically a very clear strategy on how to go from chip feature to end user product. 2011-07-31 05:00 and since there are such few copyleft hardware hackers like us, they cannot rely on us to help us with that problem, understandably 2011-07-31 05:01 even though one would think that open source is the perfect way to get a chip's feature actually adopted 2011-07-31 05:01 but in reality it's not... 2011-07-31 05:01 it's more important to work with a short-list of strategic customers behind closed doors 2011-07-31 05:01 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" 2011-07-31 05:03 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 2011-07-31 05:03 but yes, you also have the "fully closed" ones, too 2011-07-31 05:05 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 2011-07-31 05:06 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 2011-07-31 05:06 and that is typically a short-list of 5-10 companies 2011-07-31 05:06 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. 2011-07-31 05:06 when it has to be more (say because of customer fragmentation), the open strategy will be faster (=work better) 2011-07-31 05:07 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 :) 2011-07-31 05:08 and yes, those who think you'll need massive hand-holding anyway :) 2011-07-31 05:13 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 :) 2011-07-31 05:19 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 ! 2011-07-31 05:19 well, at least he said that :) 2011-07-31 05:20 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/ 2011-07-31 05:20 ptrude/ 2011-07-31 05:20 http://projects.qi-hardware.com/index.php/p/cae-tools/source/tree/master/ptrude 2011-07-31 05:21 kristianpaul: oh nice! 2011-07-31 05:21 wow that's fantastic 2011-07-31 05:21 well let's see whether/when he shows up and we'll give him a warm welcome 2011-07-31 05:22 :-) 2011-07-31 05:22 hopefully he doesn't mind openly sharing all his hardware work and discoveries... 2011-07-31 05:22 yeah, i hope the same 2011-07-31 05:22 his blog is very open, software, schmatics.. board 2011-07-31 05:22 not bad ! 2011-07-31 05:23 what EDA tool does he use? what's the license of the schematics? 2011-07-31 05:23 kicad 2011-07-31 05:23 cool! 2011-07-31 05:23 it gets better :-) 2011-07-31 05:24 actually he will send me a bare PCB, 2011-07-31 05:24 i already ordered some samples from maxim.. just to see 2011-07-31 05:25 of course it doesnt mean i will drop SiGE and my current work 2011-07-31 05:26 i cant find license afaik.. at least for PCB 2011-07-31 05:27 i'll ask him next time he reply 2011-07-31 05:27 do the steps that get you to working results the quickest 2011-07-31 05:27 whether that's on m1/sige, or the new arm/fpga/maxim combo 2011-07-31 05:28 there is nothing more motivating than getting something to work, and it helps focusing too 2011-07-31 05:28 sure :) 2011-07-31 05:28 I forgot why we went the sige route back in the day, it's already so long ago :-) 2011-07-31 05:28 but that was specfically after a comparison with maxim, by someone who had used both 2011-07-31 05:29 every chip has pros and cons, and people run into different difficulties, also depending on their own background/strengths/weaknesses 2011-07-31 05:29 bottom line: find the shortest path to working anything. I'm not worried about 'dropping' sige or m1 2011-07-31 05:30 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 :-) 2011-07-31 05:31 I believe there are some chips now that combine arm+fpga in one package, maybe even one die? 2011-07-31 05:31 why not the gnuradio approach ? collect the data on the M1 (M1 for interfacing), then send it to the PC for analyzing 2011-07-31 05:31 dunno arm at all, but also ppc i remenber 2011-07-31 05:32 is there even a problem with analyzing on the m1? I don't know where kristianpaul stands now 2011-07-31 05:32 it's so slow that I cannot measure progress :-) 2011-07-31 05:32 need a more precise measuring tool I think :-) 2011-07-31 05:32 but as i understand where things are, the problem is still to receive the bitstream into memory, no ? 2011-07-31 05:33 kristianpaul: I'm just making jokes on you, hope you don't mind :-) 2011-07-31 05:33 no 2011-07-31 05:33 wolfspraul: yeah, i kinda wonder if he isn't just going around in circles :) 2011-07-31 05:33 yeah, i kwno your jokes already 2011-07-31 05:33 no either, 2011-07-31 05:33 but seriously, finding that gnss-sdr guy and trying to team up with him is awesome 2011-07-31 05:34 the first aprouch about offline processing was bad idea, but anyway.. 2011-07-31 05:34 when you later discover the software you we're using havnnt suport for complex data, oh well.. 2011-07-31 05:34 kristianpaul: so you now can receive the bits from the RF chip and store them in memory ? 2011-07-31 05:34 yeah, but have no sense right now 2011-07-31 05:35 as the idea is make namuru to work with osgps 2011-07-31 05:35 but you're think the bits you store in memory are actually the bits the chip sent ? 2011-07-31 05:35 s/you're/you/ 2011-07-31 05:35 yes 2011-07-31 05:36 have you tried to generate a test pattern to verify this ? 2011-07-31 05:36 in simulation yes i did 2011-07-31 05:36 not in real hw afaik 2011-07-31 05:36 hmm :) 2011-07-31 05:36 he :) 2011-07-31 05:36 might be worth a try 2011-07-31 05:37 not being able to make sense of the bits you receive would be quite consistent with them just being incorrect :) 2011-07-31 05:37 once i got namuru accumulator to work, sure 2011-07-31 05:37 i dunno why is not wokring well right now.. 2011-07-31 05:37 yeah, sure, i can do that, i have sie board, so it can help to generate a know pattern and compare later in m1 2011-07-31 05:38 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 2011-07-31 05:39 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 :) 2011-07-31 05:39 ah, or with the SIE. even better :) 2011-07-31 05:40 ah yes 2011-07-31 05:40 wpwrak:Â Â yes yes 2011-07-31 05:40 i edid that with scope 2011-07-31 05:41 for clk, and ata signal 2011-07-31 05:41 i just was testing a more complex pattern 2011-07-31 05:41 like a knwo series of 4 nibbles or soemthing 2011-07-31 05:42 how wide is you register interface to the receiver in the FPGA ? 8 bits ? 2011-07-31 05:42 8 bits 2011-07-31 05:42 but thats for the acquisition core 2011-07-31 05:43 right now two bits no more i need for namuru,sign and mag no more 2011-07-31 05:43 clk, sure :) 2011-07-31 05:43 ah, so you're not working on the acquisition core anymore ? 2011-07-31 05:43 i already said, i stoped offline processing 2011-07-31 05:44 i dont wanted to spend more time on it... because osgps will never correlate complex data 2011-07-31 05:44 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 2011-07-31 05:45 i mean 2011-07-31 05:45 there's no feedback, so ... 2011-07-31 05:45 afaik the SoftGNSS code neither,, well i got a update version from fabrizzio but dint looked at it yet or planing soon 2011-07-31 05:45 sure sure, but i wanted to speed up 2011-07-31 05:45 i took me, long time to learn m1 internals (wishbone, verilog conding, HDl, RTl...) 2011-07-31 05:46 then some C, 2011-07-31 05:46 then retake gps theory and try to understand.. 2011-07-31 05:46 sure :) but it seems that you just made the problem more difficult, by adding a throughput constraint 2011-07-31 05:46 then realize my previos mistakes 2011-07-31 05:46 throughput constraint? 2011-07-31 05:46 well, or replacing an "easy" throughput constraint with a harder one 2011-07-31 05:47 dont get it.. 2011-07-31 05:47 (throughput constraint) that you have to be able to process the data in real time 2011-07-31 05:47 ah you mean because i shifted the data? 2011-07-31 05:47 ah, yes but when i was told of namuru i had very empties about gnss and dsp 2011-07-31 05:47 now i dont, well no soo much :) 2011-07-31 05:48 qwebirc83241: hi there 2011-07-31 05:48 i don't understand how namuru vs. ogpsd would affect the choice between offline/real time 2011-07-31 05:49 i picture the architecture of any such thingy as follows: 2011-07-31 05:49 qwebirc83241: hi :) 2011-07-31 05:49 1) there's some interface that picks up the data 2011-07-31 05:49 Artyom perhaps? :-) 2011-07-31 05:49 2) there's some digital filtering and such 2011-07-31 05:49 3) there's correlation and such 2011-07-31 05:50 4) there's calculation of the position 2011-07-31 05:50 5) there's some form of output 2011-07-31 05:50 maybe i skipped a few intermediate steps 2011-07-31 05:51 so it would seem that the difference between real-time processing and offline processing would be mainly in step 1 and maybe step 5 2011-07-31 05:51 it depends 2011-07-31 05:51 is this correct ? 2011-07-31 05:51 yes 2011-07-31 05:51 well, 2011-07-31 05:51 you can do soft correlation (all osgps )or hard correlation (namuru + osgps) 2011-07-31 05:53 so you're porting the baseband processor of namuru to the M1 ? 2011-07-31 05:53 it is ported, now i dealing with things dint work as spected :) 2011-07-31 05:54 i see. okay, that explains why you're still fighting with clock domains and such :) 2011-07-31 05:55 well, that already was managed 2011-07-31 05:55 how do you know before you see it work ? ;) 2011-07-31 05:55 hehe dont make mee doubt again 2011-07-31 05:55 :) 2011-07-31 05:56 *grin* 2011-07-31 05:57 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 2011-07-31 05:57 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. 2011-07-31 05:58 but afaik spartan6 popup some other issue with routing clocks, and i have to asume that for now and do a workaround 2011-07-31 05:58 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 2011-07-31 05:59 i could ask, Peter Mumford sounded friendly last time i asked to him. 2011-07-31 06:03 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. 2011-07-31 06:04 atenna, yes thats the most likelly i think 2011-07-31 06:06 ah, yes there was a ugly truought limitation with mm1, for the ethernet part, 2011-07-31 06:07 even in complex mode, too much data to transmit and no enogutht bandwicth.. and of course no way to decimate 2011-07-31 06:08 hmm, how much data does the sige generate ? 8 Mbps ? 2011-07-31 06:09 and how long do you need to receive before the algorithm can "see" something ? 30 seconds ? more ? 2011-07-31 06:09 I think it can theoretically be many minutes, curious what kristianpaul says... 2011-07-31 06:10 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. 2011-07-31 06:10 wolfspraul: you mean the almanac ? 2011-07-31 06:11 yes, maybe that, not sure 2011-07-31 06:11 wpwrak: in complex mode 2.048MSPS (4 bit sample), real mode 16.384MSPS (2bit sample) 2011-07-31 06:12 wpwrak: remenber gps telemtry is 50bps 2011-07-31 06:13 sure you can cheat and get a fresh almanac and load to osgps, also give a warm position, so things can speed up 2011-07-31 06:14 s/cheat/optimize/ ;-) 2011-07-31 06:14 sure, 2011-07-31 06:15 and yes, every 30seconds you get a frame if remenber well 2011-07-31 06:15 have you successfully decoded an entire navigation message yet ? 2011-07-31 06:15 NO 2011-07-31 06:15 :-) 2011-07-31 06:15 ah, no need for an almanac then :) 2011-07-31 06:15 no yet 2011-07-31 06:16 i confir signal, but wasnt able to track it.. 2011-07-31 06:16 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) 2011-07-31 06:17 of course at leat in 12 seconds or less no 6, you can get a TLM 2011-07-31 06:17 with real data, that's 4 MBytes * 60 = 256 MB. hmm. can M1 store to uSD ? 2011-07-31 06:17 NO 2011-07-31 06:17 :( 2011-07-31 06:17 with complex data it would only be 60 MB ... 2011-07-31 06:18 i created a ramdisk in rtems for data 2011-07-31 06:18 but afaik all samples i have are complex 2011-07-31 06:18 and you can't arithmetically convert complex to real ? 2011-07-31 06:19 i dont know how but in therory yes, 2011-07-31 06:19 but is not worth 2011-07-31 06:19 like inÂ Â r = hypot(q, i); 2011-07-31 06:19 every complex sample is 4x a real one 2011-07-31 06:19 i undertand 2011-07-31 06:19 well, you would have a lot less data, it seems 2011-07-31 06:23 (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.) 2011-07-31 06:24 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. 2011-07-31 06:24 every subframe (6s each) have a 8 bits preable so you can catch that and sync the rest from there 2011-07-31 06:24 aah, i see 2011-07-31 06:25 and you've received and decoded subframes yet ? 2011-07-31 06:25 no, as i said just detected signal, 2011-07-31 06:25 but i'm working on it 2011-07-31 06:26 (TLM) ah, i see that there's more than one in a message. that helps. 2011-07-31 06:27 once the accumlator works, i can do a loop that will slew the code nco until get a interesting treshold 2011-07-31 06:28 of course this loop isnt aware of dopler.. and a moving satellit, 2011-07-31 06:28 so thats whenaÂ Â "pull-in" algorthm saves the day :) 2011-07-31 06:28 pick a satellite on a tangential course ;-) 2011-07-31 06:28 sure i can 2011-07-31 06:29 gpredict tell me 2011-07-31 06:29 or maybe one that's stopped for maintenance :-)) 2011-07-31 06:29 lol 2011-07-31 06:30 you needÂ Â that subframe before now satelly health.. 2011-07-31 06:30 s/now/know 2011-07-31 06:32 that could be donne in india,i think their gnss implementation dont move so much... 2011-07-31 06:33 (gpredict) nice :) 2011-07-31 06:33 gpredict plus a fucunbe dongle is great, you can get weather telemtry, listen ISS.. and what not 2011-07-31 06:37 aah, that's what you want the funcube for ! 2011-07-31 06:38 yeah, i need an updated forecast :) 2011-07-31 06:39 also listen some cubesatswith open telemetry 2011-07-31 06:39 even a coming artist related sat, (sat.mur.at) 2011-07-31 06:40 and my prefered FM station ;) 2011-07-31 06:53 hmm, no GPS satellites over the south pole. that's about the worst place to have your GPS fail :) 2011-07-31 06:56 hah 2011-07-31 06:59 hmm, gpredict seems to lack a nice trajectory view. e.g., something like the trajectory for the next hour 2011-07-31 06:59 and it's hard to get rid of the ground area 2011-07-31 07:15 you can modify time 2011-07-31 07:16 buy yeah, there are some shortcomings for prediction.. 2011-07-31 07:32 tuxbrain: (cad) that is ... maybe i do have a solution for the extrusion problem that's not too hard to implement ... hacking ... 2011-07-31 07:56 zz 2011-07-31 07:59 kristianpaul: caffeine ! 2011-07-31 08:04 wpwrak: tea dint worked well... 2011-07-31 08:04 Is anyone here? ;) 2011-07-31 08:04 hi Artyom 2011-07-31 08:04 nice to see you around :) 2011-07-31 08:04 hi KristianPaul :) 2011-07-31 08:05 thank you. I've seen your discussion here couple of hours ago - very interesting ;) 2011-07-31 08:06 ah,yes wpwrak always made good questions :) 2011-07-31 08:06 I face very similar problems with debugging hardware... 2011-07-31 08:06 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? 2011-07-31 08:06 btw, before i fogot what's the license of gps_for_www.zip ? 2011-07-31 08:07 Artyom: how you sort it out? 2011-07-31 08:08 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? 2011-07-31 08:10 dual lincense GLPv3 and CC-BY-ShareAlike version 3.0 :) 2011-07-31 08:12 And how it can be done? I only have to add a text file with license to the source? 2011-07-31 08:13 yeah, a file called LICENSE should be okay for thre PCB design i think.. 2011-07-31 08:16 ok, I will add such a file. 2011-07-31 08:17 LICENSE or COPYING are common names. sometimes people also put licensing information into a README. here's an example from one of my projects: http://projects.qi-hardware.com/index.php/p/ben-wpan/source/tree/master/COPYING 2011-07-31 08:17 (this one has GPL v2+, LGPL v2.1+ and CC-BY-SA 3.0) 2011-07-31 08:18 thanks for this example :) 2011-07-31 08:18 so many questions, also i'm curious about your work around osgps, and the fpga-arm board.. 2011-07-31 08:19 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 ? 2011-07-31 08:21 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. 2011-07-31 08:21 But it is very slow 2011-07-31 08:21 For traking I tried to work with real signal from antenna 2011-07-31 08:22 But with no success for now 2011-07-31 08:22 the test with the file would be in a simulator ? 2011-07-31 08:22 But I used my own code for tracking wich I checked in matlab/scilab with Akos code 2011-07-31 08:23 Test file was made with my hardware (gnss-sdr front-end) 2011-07-31 08:24 And I processed this file with matlab/scilab code to find out which satellite are in view (and to know doppler) 2011-07-31 08:24 But 2011-07-31 08:24 tracking doesn't work now 2011-07-31 08:25 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. 2011-07-31 09:01 The build has FAILED, see log here: http://fidelio.qi-hardware.com/~xiangfu/compile-log/openwrt-xburst.full_system-07302011-0543/ 2011-07-31 12:26 zedstar: did sujan publish any blog post about the nepal trip? 2011-07-31 14:06 oh, i dint knew tha tracking dint worked... 2011-07-31 14:06 or he meant that for the simulated data? 2011-07-31 14:09 wolfspraul: nice choice from ME cartoon :-) 2011-07-31 14:09 yes 2011-07-31 14:10 tomorrow is 08-01 2011-07-31 14:10 I am so totally behind again 2011-07-31 14:10 cleanup more tomorrow... 2011-07-31 14:13 ok. i'll try to cleanup what i wrote there then 2011-07-31 14:16 he :-) thanks! 2011-07-31 14:16 but no worries I'll go through... 2011-07-31 14:24 great, no worried now then :) 2011-07-31 14:33 wolfspraul: hmm, no word about atben/atusb production finishing and them being available now ? june only had the pcbs, no smt/testing/shop yet 2011-07-31 14:42 milkymist news: rc3 boards have been made and are being tested 2011-07-31 14:44 nanonote: maybe my test point map ? http://lists.en.qi-hardware.com/pipermail/discussion/2011-June/008140.html 2011-07-31 14:45 milkymist: openwrt !!! 2011-07-31 14:47 milkymist: maybe also point to all the "paperwork" - leaflet, flyer, box ? 2011-07-31 14:47 wpwrak: please edit the wiki 2011-07-31 14:47 openwrt is nice to quoute indeed 2011-07-31 14:51 (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 2011-07-31 14:52 hhaha, come on 2011-07-31 14:52 dump it here http://en.qi-hardware.com/w/index.php?title=Copyleft_Hardware_News_2011-08-01 2011-07-31 14:53 remove is prety easy, so cares about it :) 2011-07-31 14:53 qi-hw general: maybe that CERN is now also officially interested in open hw ? http://lists.en.qi-hardware.com/pipermail/discussion/2011-July/008409.html 2011-07-31 14:53 no cares* 2011-07-31 14:53 yes it seems 2011-07-31 14:55 he even sabastien http://www.ohwr.org/projects/tdc-core 2011-07-31 14:55 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. 2011-07-31 14:55 ok no more excuses, 2011-07-31 14:59 nanonote: maybe also the navigation board, for which volunteers are wanted ? http://lists.en.qi-hardware.com/pipermail/discussion/2011-June/008344.html 2011-07-31 15:00 tuxbrain: also offered some stuff for people interested to work in arduino support for atben 2011-07-31 15:00 dunno if he want such us publicity? 2011-07-31 15:01 i don't remember seeing that 2011-07-31 15:04 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? 2011-07-31 15:06 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. 2011-07-31 15:06 wolfspraul: if you want you could do some pre-marketing for the mm1 batch with this photo http://yamato.hyte.de/tmp/logotest/SANY0029.jpg 2011-07-31 15:07 something like 'will feature the new logo' or so 2011-07-31 15:07 wolfspraul: hi....he came back a couple of days ago so will chase all that up....out there it was hard to do anything internet related 2011-07-31 15:12 wpwrak: arent there already such boards? 2011-07-31 15:12 http://www.logos-electro.com/zigduino/ 2011-07-31 15:15 roh: we wanted to make a really small one 2011-07-31 15:15 s/we/he/ 2011-07-31 15:31 wpwrak: ah. so like a smd-jeenode with an atrf? 2011-07-31 15:32 and pcb antenna? 2011-07-31 15:32 dunno jeenode. i think the one he had in mind is some nano-arduino. dunno about the antenna 2011-07-31 15:33 btw anyone know a code snipet to convert and integer toÂ Â char bar? 2011-07-31 15:34 kristianpaul: i used something like that.. on arduino.. mompls 2011-07-31 15:36 LcdBarGraph.cpp 2011-07-31 15:37 can you pastebin it somwhere? 2011-07-31 15:39 kristianpaul: while (n--) putchar('#'); putchar('\n');Â Â ? :) 2011-07-31 15:39 http://pastebin.com/MZJGB8iB http://pastebin.com/3K7e2t3K 2011-07-31 15:40 found it on the web somewhere and patched it to allow multible bars in multiple lines and starting locations 2011-07-31 15:40 -LcdBarGraph::LcdBarGraph(LiquidCrystal* lcd, byte numCols) 2011-07-31 15:40 +LcdBarGraph::LcdBarGraph(LiquidCrystal* lcd, byte numCols, byte startCol, byte startRow) 2011-07-31 15:40 hum... 2011-07-31 15:42 it draws the bars by using the lcd lib and these predefined special chars 2011-07-31 15:42 not wat i was looking for, for i ditn knew it of this putchar() xD 2011-07-31 16:04 grmbl. meshlab is really trying my patience ... 2011-07-31 16:17 okay the carrier NCO is getting stuck.. why?.. 2011-07-31 16:19 roh: thanks for the heads up about picture! yes, that's the nicest of the 4, you are right. Will mention it. 2011-07-31 16:56 thought about CF-6lowpan 2011-07-31 16:56 may be useful for CF-only devices 2011-07-31 16:57 e.g. for zauruses which have no wireless ifaces (except SL-6000l/w) 2011-07-31 20:20 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 :) 2011-07-31 21:03 hi Artyom 2011-07-31 21:04 hi Kristieanpaul :) 2011-07-31 21:04 16:04 here 2011-07-31 21:04 Sorry that I have to leave very soon last time 2011-07-31 21:05 np, actually i got sleep at that time :) 2011-07-31 21:06 I read that you faced similar problems with debugging osgps+namuru 2011-07-31 21:06 well, currentlyÂ Â the carrier nco is not working.. 2011-07-31 21:06 but yes with osgps itseld i wasnt able to track signal 2011-07-31 21:07 In my case I think that the problem is in interface between arm7 and fpga. 2011-07-31 21:07 wich fpga are you using? 2011-07-31 21:08 Thay are connected through a async static memory interface 2011-07-31 21:08 oh 2011-07-31 21:08 I use spartan 3e and lpc2478 2011-07-31 21:09