<DocScrutinizer> (sw for antenna simulation and R&D) rarely anything. Basicaly it's still not possible to *accurately* compute antennae
<DocScrutinizer> there are a few algos for well known models, lika yagi
<DocScrutinizer> like*
<DocScrutinizer> of course for parabolic it mostly should work as well
<DocScrutinizer> but calculate the gain in dB of a random wire bent to some shape of your liking? nope
<wpwrak> oh, there are simulators. but they're kinda hostile ... (or non-open)
<DocScrutinizer> yes, and not really accurate enough. AFAIK all industry tests with real models, as they yield different results than the simulators
<DocScrutinizer> seems it's a variation of the 3+ planets problem. Really hard and expensive to calculate, and never exact
<DocScrutinizer> special class of strange attractors
<wpwrak> maxwell's demon :)
<DocScrutinizer> umm
<DocScrutinizer> wasn't the maxwell daemon only to know, but not to extrapolate?
<wpwrak> maybe he has other skills :)
<DocScrutinizer> oooh I first got it right, then mixed up maxwell with laplace
<DocScrutinizer> can't see how maxwell's daemon is related
<DocScrutinizer> btw I reinvented maxwell's daemon in school when I was 14 years old :-D. My physics teacher wasn't completely convinced I never before heard of maxwell's daemon when I asked him about where the energy goes when just pouring warm water into cold water, and if it was possible to "unmix" them again
<wpwrak> heh ;-) and at 15, he flunked you when you proved the existence of "dark matter", right ? :)
<wpwrak> and then, at 16, they made you see a therapist when you explained that there are nearly weightless particles, that almost never interact with matter, that spontaneously change into other, similar, particles and back, and that travel at the speed of light or slightly faster
<DocScrutinizer> nah, none of that
<DocScrutinizer> btw I'm not convinced about existence of dark matter even today
<DocScrutinizer> at least that stuff must be really strange, as it's obviously not forming planets or stars, despite allegedly obeying law of gravity
<wpwrak> yeah, it's one of the more dubious concepts. has that strong smell of aether on it :)
<wpwrak> maybe dark stars :)
<qi-bot> [commit] Xiangfu Liu: nanonote-files: update feeds.conf for next release (master) http://qi-hw.com/p/openwrt-packages/fe24c6b
<qi-bot> [commit] Xiangfu Liu: makfa: add makfa.dump to files. not generate every build (master) http://qi-hw.com/p/openwrt-packages/bf77201
<kyak> viric: hey, that sounds great. What kind of functionality for offrss do you think about?
<viric> kyak: something like getting a list of only-titles, for feeds in a group
<viric> To handle so much data as you need... there should be some code 'removing posts' there
<kyak> that would be usefull for some feeds, where only title matters
<viric> kyak: there are some people publishing almost only title and hyperlink
<kyak> yes, there are :)
<viric> kyak: for your use case, you could use some 'rss2title URL | grep ...'  :)
<kyak> that's basically what i did before, curl URL | grep | sed & etc
<kyak> and than i have the download magically in rtorrent
<kyak> from my opinion, the best new feaure would be a "mark all as read" (for a group or for a feed) - but i don't know how hard is it to implement it
<viric> kyak: easy easy
<kyak> viric: well, when you need testing, just let me know ::)
<viric> ok :)
<whitequark> wpwrak: remember that my LVDS thingy?
<whitequark> IT WORKS!!
<whitequark> a console with a penguin is displayed at least :D
<wpwrak> congratulations ! :-) that was quite a battle
<whitequark> yeah
<whitequark> but now I can make happier quite a few people
<whitequark> I already have a second order :D
<whitequark> (a battle) IMO, a pretty regular debugging routine, isn't it?
<whitequark> I don't think that even atben or of course the ben itself were any easier
<wpwrak> well, they were different :)
<wpwrak> the basic stuff worked quickly. but getting the RF right was a little harder
<kyak> larsc: do you which of the USB Gadget Drivers would work for Ben? I tried a few so far, none of them works (except for USB_ETH)
<whitequark> wpwrak: http://rghost.ru/26276911/image.png :)
<larsc> kyak: i think i only tested USB_ETH so far
<whitequark> kyak: try the CDC-ACM
<whitequark> it may work
<kyak> whitequark: that i tried, it doesn't work
<whitequark> it works on 4750l, and it has the same usb gadget as 4740
<whitequark> hmmm
<whitequark> strange
<kyak> whitequark: the composite driver or..?
<whitequark> kyak: the composite driver?
<kyak> larsc: i see.. i thought USB_CDC_COMPOSITE would work (CDC ECM for Linux and CDC ACM for Windows, which doesn't have ECM driver)
<kyak> whitequark: i'm trying now the USB_G_SERIAL
<wpwrak> whitequark: nice !
<whitequark> kyak: IIRC 4740 usb gadget does not have enough descriptors or whatever for ECM+ACM tow ork
<whitequark> *to work
<whitequark> wpwrak: thanks
<larsc> kyak: are you getting any error messages in dmesg?
<kyak> no, it's quite at all
<kyak> like i'm not plugging anything
<kyak> damn, kernel_menuconfig is so broken, i can't configure the kernel correctly..
<kyak> whitequark: yeah, USB_G_SERIAL works fine (at least on Linux, still doesn't work for Windows)
<kyak> but this config is not so interesting anyway..
<whitequark> kyak: as I've said, when I've looked at it, it turned out that the UDC does not have sufficient resources to run the combined configuration
<whitequark> unless you'll hack it to do so, of course
<kyak> that's pretty strange though because i want it to run one configration a time
<kyak> not both configurations concurrently
<whitequark> kyak: then, you should not use a combined one
<whitequark> just compile both ECM and ACM  as modules and load the one which you want to use currently
<whitequark> it's proven to work
<whitequark> or ETH, that works with any gadget
<kyak> whitequark: yes, compiling both as modules makes sense..
<whitequark> it's the way it works
<kyak> whitequark: are you saying that ETH supports ACM, too?
<whitequark>   
<whitequark> kyak: nope, it doesnt
<whitequark> they are different gadgets
<whitequark> ~/.
<whitequark> darn.
<whitequark> sorry, crappy WiFi
<kyak> whitequark: ok, thnkas
<Artyom> Hi Kristianpaul
<kristianpaul> Artyom: hello!
<Artyom> how is your work with gps?
<kristianpaul> signed problem solved, but i have some problems when reading memory :/
<kristianpaul> my fault..
<kristianpaul> I'm working on solving, actually you are using a DCM in your board isnt?
<kristianpaul> The problem is that namuru core clock is 8Mhz and the SoC clock is 80Mhz
<Artyom> yes, I use DCM to generate 80MHz clock for FPGA from 16MHz clock from my front-end
<kristianpaul> yes, well i'm working on solve that, i just found a solution but is vhdl so i need port it
<kristianpaul> so it should avoid cross clock domain issues using a fifo
<kristianpaul> btw i was checking your code, so i think can be easy ported later, also i'll re-use that mprintf function :)
<kristianpaul> So far, thats my status
<kristianpaul> How is yours?  what about your students projects?? all related with gnss-sdr? :-)
<Artyom> mprintf is not mine ;) I've found it in internet ;)
<Artyom> I switch to some other tasks related with glonass. especcially with the new cdma signal.
<kristianpaul> ah sure, yes :)
<Artyom> and i also spend some time on planning future front-end. I want to make dual frequency glonass/gps front-end
<kristianpaul> oh
<Artyom> students are rather lazy and unpredictable ;) Actually I was the same...
<kristianpaul> What about processing? still want to use the usb for transfer data to pc or  want do soemthing in same board with arm+ fgpa¿
<kristianpaul> laaaazy
<Artyom> I want to make something universal: the device should be able to transmit data to PC through USB 2.0 and to process data autonomously
<kristianpaul> thats fair
<Artyom> And I want to split analogue and digital parts. Each part should be made on a separate pcb
<kristianpaul> that will be great, also will allow re-use the anloag part in other projects ;-)
<Artyom> But now I'm mainly busy with software processing... And I have to prepare couple of articles...
<kristianpaul> Artyom: what you think about i run namuru at same clock of my soc, and uses dcm to to something inverse to decime with the coming I/Q signals??
<Artyom> What is the quartz-generator that you want to use?
<kristianpaul> sorry i don understand
<kristianpaul> dont*
<Artyom> GPS devices usually use TCXO or even OCXO.
<kristianpaul> ah, you mean the clock for the SoC?
<Artyom> I mean what kind of clock do you want ot use?
<kristianpaul> for namuru i want to use the same clock as the main soc
<kristianpaul> yes, my front end have own TCXO
<Artyom> So as I understand you want to use mylkimist clock for your gps front-end?
<kristianpaul> but the problem is that data is sampled at 8mhz, how i can still read it if my system (and namuru)uns at 80Mhz
<kristianpaul> may be
<Artyom> or you want to use gps front-end clock as the main clock?
<kristianpaul> I wish i could, but the exp connector i have dont have pins for mail clock signals afaik
<kristianpaul> thats why i'm dealing with two clocks and crossing its domains
<Artyom> So your problem is that front-end and mylkimist use different clocks?
<kristianpaul> yeap
<Artyom> Once again
<Artyom> Can you take front-end clock and use it in mylkimist?
<kristianpaul> i could try yes, hoping synthesis will pass trought
<kristianpaul> right now i'm suing that front-end clock in a slave core (namuru) of the mylkimist
<kristianpaul> but not in the whole soc
<Artyom> you can use DCM in FPGA to multiply front-end clock. Like it's done in my example
<kristianpaul> yes i think could try at least
<Artyom> sorry... how you do it now?
<kristianpaul> i can change some pin asgiments in the  .ucf files plus modify a bit the dcm milkymist already uses
<kristianpaul> right now namuru is a slave core in the milkymist soc, it uses clock from front-end and there is a no very good clock domain crissing "bridge" that is giving me problems :/
<kristianpaul> i think thast was you asked for, right?
<Artyom> yes
<Artyom> I think the simplest way is to use front-end clock for everything...
<kristianpaul> Sure, i do think same, actually in the end i will still need the milkymist cpu for the aquisition and tracking
<kristianpaul> so that make sense...
<kristianpaul> I could try that o the milkymist one board or implement a small soc in other board i have
<kristianpaul> how much ram do you need for acquistion and tracking algortym only?
<Artyom> that's a good question ;)
<Artyom> How can I measure it?
<kristianpaul> i guess srtating by the size of your osgps
<kristianpaul> binary
<Artyom> i will check it tomorow
<kristianpaul> may wpwrak knows how stimate amount of ram a c program will need.
<Artyom> btw is it difficult to implement in fpga a cpu+other? Never done it before...
<kristianpaul> no at all
<kristianpaul> well you'll hit this clock domains issues, but always there is a workaroudn :)
<kristianpaul> you know milkymist one already, isnt? cpu is mico32 from alttice
<kristianpaul> s/alttice/lattice
<Artyom> yes, i've read a little about it. btw I thoought that mico32 can only be used with lattice fpga's...
<kristianpaul> of course is not:) i tought same then foudn milkymist project a year and half from now :)
<kristianpaul> there is people i  cern i read at #milkymist using mico32 in altera fpga's so thats good too
<Artyom> and there are problems with licence and etc?
<Artyom> *no problems
<kristianpaul> zero, there was a minor missing clarification in mico32 license but that was fixed in last release
<kristianpaul> as we stay away from mips and arm implementation in fpga, all is okay so far :)
<Artyom> and what tools are used to compile programs? And how everything is working? ;) Is there any tutorial in the web?
<kristianpaul> mico32 is supported by gcc
<kristianpaul> there is also a rtems port
<kristianpaul> wich curerntly works as the base software in the milkymist one first market aplication wich is video synthesis
<kristianpaul> Here there are some presentations
<kristianpaul> you can skip french :)
<Artyom> last question: what is the minimum hw requirements to implement mico32 in FPGA?
<kristianpaul> also you are invented you join #milkymist at any time
<Artyom> thanks for links :)
<kristianpaul> let me find requirements in LE
<kristianpaul> btw here is a small port https://github.com/fallen/milkymist-avnet
<kristianpaul> prety basic just lm32, uart sram and vga
<kristianpaul> Artyom: http://paste.debian.net/138098/
<kristianpaul> Is around 2500 LE for spartan6, i still looking to confirm
<kristianpaul> so is pretty small i think
<Artyom> yes, I should test it ;)
<kristianpaul> about if it works, well check some videos http://www.youtube.com/user/xiangfuliu
<kristianpaul> but, everything work for the VJ app, and still somw work to do for getting linux run better on it (missing drivers)
<kristianpaul> and of course best usb stack and support for it
<kristianpaul> ah, just in case http://en.wikipedia.org/wiki/Milkymist
<Artyom> the idea to use only one fpga without additional cpu is attractive. The only thing that terrifies me is debugging
<kristianpaul> jtag is WIP, you may want ask mwalle at #milkymist for mode detail
<kristianpaul> i personally use serial port and bios for debuging :)
<kristianpaul> i still on the printf and led blink era :)
<kristianpaul> s/mode/more
<C-Keen> which is not a bad approach
<C-Keen> In my experience debuggers help only find certain bugs quickly, mostly doing a post mortem analysis of some kind of memory dump
<kristianpaul> also there is qemu port, i'm not sure but i think is a valid way to debug software once you learn how customize the port :)
<whitequark> you'll then need to write both software and port updates to be compatible with the real "hard"ware
<whitequark> compared to only the software
<kristianpaul> you write hardware you can trust more ;)
<whitequark> kristianpaul: hm?
<kristianpaul> whitequark: in qemu
<kristianpaul> simulate hardware behavior at register layer, etc.. i guess
<whitequark> kristianpaul: well, it's easier to do the same error in qemu & sw layer
<whitequark> just because you write both
<whitequark> and then you'll think for a week why it does not work on the real thing
<Artyom> and what is qemu? ;)
<kristianpaul> Is a computer emulator like propietary equivalents, vmware virtual pc
<Artyom> Kristianpaul thanks for all the information. Very useful for me :)
<kristianpaul> :-)
<Artyom> it'm time to sleep for me... bye :)
<kristianpaul> bye
<ignatius-> I've been playing around with the accelerated port of MPlayer to the Ben. I can get the video, but no the audio.
<ignatius-> s/no/not