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
panda|x201 has joined #qi-hardware
cladamw has joined #qi-hardware
<wolfspraul>
good morning :-)
<abushcrafterforg>
good morning.... arr is 2 am
wolfspraul has joined #qi-hardware
Guest79790 has joined #qi-hardware
wolfspra1l has joined #qi-hardware
wolfspra2l has joined #qi-hardware
<wolfspra2l>
blist
unclouded has joined #qi-hardware
mirko has joined #qi-hardware
mirko has joined #qi-hardware
AwAyla has joined #qi-hardware
Artyom has joined #qi-hardware
wolfspraul has joined #qi-hardware
wolfspraul has joined #qi-hardware
jekhor has joined #qi-hardware
wolfspraul has joined #qi-hardware
rejon has joined #qi-hardware
jluis has joined #qi-hardware
kilae has joined #qi-hardware
indistylo has joined #qi-hardware
DocScrutinizer has joined #qi-hardware
wolfspraul has joined #qi-hardware
LunaVorax has joined #qi-hardware
rejon has joined #qi-hardware
wolfspraul has joined #qi-hardware
<whitequark>
DocScrutinizer51: APE?
rejon has joined #qi-hardware
<wolfspraul>
wpwrak: I'm wondering how susceptible to RF interference atben/atusb is compared to a RF keyboard
<wolfspraul>
so for example, you take your rii rf keyboard, and you have a lot of 2.4 ghz wifi noise around - do you experience problems with the keyboard? how about atben/atusb in comparison? any insights?
<wolfspraul>
I think I will start to watch this a bit more, and test in noisy environments...
rektide has joined #qi-hardware
GNUtoo|laptop has joined #qi-hardware
wolfspraul has joined #qi-hardware
wolfspraul has joined #qi-hardware
<wpwrak>
wolfspraul: (interferences) like wlan, it is affected by interferences
<wpwrak>
the rf keyboard will have the same issue. it's just a little harder to notice.
<wolfspraul>
ok, that's quite vague :-)
<wpwrak>
also don't forget that received energy drops with distance squared. as long as sender and receiver are close to each other, interference rarely matters. it's when distances grow when the problems start
<wpwrak>
oh yes, RF is all about being vague ;-))
<wolfspraul>
you have been using both the RF keyboard and atben/atusb quite a lot, and you have at least 1 wifi network as well, maybe a few more from neighbors
<wpwrak>
there are countless factors that affect this. also frequency separation, channel width (of the "good" signal but also of the interferers), signal path characteristcs, etc.
<wolfspraul>
what RF technology is used by the RF keyboard?
<wolfspraul>
yes sure, but I am wondering how atben/atusb does compared to say the 'typical' RF keyboard
<wolfspraul>
let's say you are in a very wifi-noisy environment
<wolfspraul>
maybe the answer right now is simple: we don't know
<wolfspraul>
simply
<wpwrak>
i think it's some proprieatry 2.4 GHz stuff. presumably somewhat similar to 802.15.4. perhaps with less efficient modulation.
<wpwrak>
atben/atusb should get a little further than the average rf keyboard
<wpwrak>
e.g., mine is good only up to 3-4 m straight line of sight. atben/atusb can do 7 m and more around corners
<wpwrak>
atben and atusb operate at comparably low power. only 2 mW. in the 2.4 GHz band, you can usually go up to 100 mW. so other IEEE 802.15.4 devices (those with extra amplifiers) may be able to go almost ten times as far.
<whitequark>
DocScrutinizer: nope, I only looked at the file which was downloaded into the modem at powerup
<whitequark>
(it doesn't have its own flash)
<DocScrutinizer>
yep, I know that design
<DocScrutinizer>
the very first file transferred to modem is mcore, basically the OS
<DocScrutinizer>
the domain I work for
<DocScrutinizer>
then this file gets checksummed and started, and it loads next file which usually is NS (network signalling, the LTE/UMTS stack)
<DocScrutinizer>
though after mcore got loaded, the load sequence of other load-modules is not strictly defined, they may change depending on packaging
<DocScrutinizer>
whitequark: could you pastebin the output of strings?
<DocScrutinizer>
and maybe also a od|head -n 100
<whitequark>
DocScrutinizer: sure, I'll be back in a hour
<DocScrutinizer>
np
<DocScrutinizer>
no access to all that any sooner than monday ;-D
<DocScrutinizer>
today is WEEKEND, and my RF-thermomenter tells me it's 14°C outside \o/
<whitequark>
DocScrutinizer: there are 9683 strings longer than 32 bytes
<whitequark>
also, that BP is xgold626, if that'll tell you something
<DocScrutinizer>
BP?
<whitequark>
baseband processor?
<DocScrutinizer>
BB
<whitequark>
and the second B stands for?..
<DocScrutinizer>
DBB and ABB, for digital and analog, what we call companion chip at OMAP
<DocScrutinizer>
BaseBand
wolfspraul has joined #qi-hardware
<whitequark>
ah. in the pre-Android motorolas, they were AP and BP (Application Processor and Baseband Processor). looks like the naming is different in different companies.
<DocScrutinizer>
I'm sure there's no ISO standard for that ;-)
<kristianpaul>
I noticed you are playing with interrupts ;)
<kristianpaul>
"uart-data-transmition occupies a lot of cpu-time" hmm
<kristianpaul>
"Delay, phase and frequency discriminators must be optimized! Otherwise tracking of more then 2"
<kristianpaul>
channels will be impossible.
<kristianpaul>
how do you know it occupies lot of cpu time?
<kristianpaul>
btw i havent checked your namuru verilog port
<kristianpaul>
but i'm aware there are some posible related to a not very good mix of blocking and non-blocking asigments
<kristianpaul>
that could explain at first un-stabillity on the correlator
<kristianpaul>
btw what ISE version are you using?
<Artyom>
I use 12.4 (if I remember correctly)
<kristianpaul>
13.4 is last and recomended vesion for milkymist soc :)
<Artyom>
It was very easy to check how long interrupt are processed with accum_int output and socillosccope
<kristianpaul>
not very constant graph?
<kristianpaul>
last time i did was very funny to see that on scope
<Artyom>
When uart transfer occures (approximately once per 1 second) then interrupt-function lasts more then 1 ms. That is not good
<Artyom>
The same picture when 3 channels are working in parallel
emeb has joined #qi-hardware
<kristianpaul>
What keep busy uart? too many printf/put i guess
<Artyom>
But there are a lot of possibilities to optimize the code. So it shouldn't be a problem
<kristianpaul>
yes it is damn slow.. i remenber :/
<kristianpaul>
not use too much printf ? ;)
<kristianpaul>
mprintf*
<Artyom>
yes, I try to use it as few as possible. But I cannot refuse from it because it is the only way to output data from program to external world
<Artyom>
May be I should look for a faster uart-core. Or write my own
<kristianpaul>
may be buffer first and transfer later, 128Mb is plenty for some samplint?
<kristianpaul>
write own.. could be
<kristianpaul>
i know this uart is no desing for heavy transfers
<Artyom>
But I want to check how tracking is working. I want to compare results with other receivers
<Artyom>
So data must be output in real-time mode
<kristianpaul>
what other receivers you mean? i mean.. ergh what other receivers allow debug tracking?
<kristianpaul>
What is your soc speed?
<kristianpaul>
wich gcc toolchain version are you using for lm32?
<kristianpaul>
for those transfer the best will be ethernet using udp(tftp) my opinion
<kristianpaul>
but yeah, is clear m1 soc was not designed for such tasks..
<Artyom>
I mean I want to compare Doppler for one of the satellites generated by my program with Doppler calculated with some hardware receiver
<kristianpaul>
ah, benchmark Lab :-)
<kristianpaul>
nice
<Artyom>
gcc.... I think I downloaded some scripts for MM1. And they downloaded gcc, gdb and so on.
<kristianpaul>
ah good
<Artyom>
Well, yes. Ethernet can be a good solution. But not for me ;)
<kristianpaul>
Get an M1 !! ;-)
<kristianpaul>
s/an/a
<qi-bot>
kristianpaul meant: "Get a M1 !! ;-)"
<kristianpaul>
of course this dont work out of the box.. still code to write for those features..
<kristianpaul>
tftp works just as client last time i cheked..
<Artyom>
I played with it too. Downloaded software in MM SoC
<kristianpaul>
lunch, back in a some minutes
* kristianpaul
back
jekhor has joined #qi-hardware
<Artyom>
I use 48 MHz system clock (16*3)
<Artyom>
Kristianpaul: It's very interesting for me if you could run namuru-core and my program on your MM1. May be you will be able to run your system with higher frequency
<kristianpaul>
oh
<kristianpaul>
Well, i could do another port yes
<kristianpaul>
To be sincere i dont like the baseband implementation method
<kristianpaul>
bu yes i could, plus solder the maxim receiver..
<kristianpaul>
I think clear register must be separate
<Artyom>
What do you mean by "baseband method"? I think you can use your front-end
<kristianpaul>
yes sure i can use fronted
<kristianpaul>
Artyom: i meant basically that there are separate address for writing and reading same register
<kristianpaul>
moment
<kristianpaul>
anyway i could run it yes
<kristianpaul>
Artyom: i want to be able for example to read back a value when writing prn code for example
<kristianpaul>
thats is currently no posible
<kristianpaul>
and implement it yes, but i will need two register for that..
* kristianpaul
stubborn
<Artyom>
Yes, prn-reading is not realized in namuru...
<kristianpaul>
he indeed ;)
<Artyom>
But what are the reasons for such implementation? Just curious...
<kristianpaul>
he
<kristianpaul>
I want to debug when is that register cleared :)
<kristianpaul>
I just debug
<kristianpaul>
s/I/Is
<qi-bot>
kristianpaul meant: "Is just debug"
<Artyom>
Why not to use simulator for this task?
<kristianpaul>
i havent written the test bench, but good point
<Artyom>
oh, seems I should publish mine...
<kristianpaul>
i prefer write test in software for now :)
<Artyom>
to test cores in hardware? ;)
<kristianpaul>
yes
<kristianpaul>
why? because i dont know what xilinx sintheize at the end and posible timing bugs i dont know off..
<kristianpaul>
i dont trust xilinx tools
<Artyom>
Yeah, I understand you very well. I also tried to start hardware testing as soon as possible.
<Artyom>
But after spending a huuuugggeee amount of time on finding simple errors in verilog/vhdl I prefer to simulate as much as possible...
<kristianpaul>
I use gplcver fot simple errors
<kristianpaul>
but yes i got the point
<Artyom>
I used icarus-verilog. But I want to test verilator. As simulating in icarus verilog is extermely slow for namuru-testing
<kristianpaul>
oh indeed
<whitequark>
wolfspraul: was the ethernet cable included with m1 specifically designed to be exceptionally hard to remove?
<whitequark>
because I can't do that without two screwdrivers.
<kristianpaul>
ethernet?
<kristianpaul>
hmm no
<whitequark>
which isn't very convenient or a well-known requirement for ethernet cables.
<whitequark>
kristianpaul: it has some really stupid kind of rubber latch
<kristianpaul>
you need remove top of the case to plug usb cable