<wolfspraul>
rjeffries: how do you measure that the 'acceptance of NanoNote is low'?
<wolfspraul>
if I wouldn't be too lazy, I would look up all the hundreds of ways Steve Jobs ridiculed 'market share' over the years
<wolfspraul>
the goal was to sell 3000 (no real time frame), we sold 1200-1300 so far.
<wolfspraul>
oops
<wolfspraul>
it is correct that the sales and marketing activity has hit a bump, but I find that a very interesting challenge
<wolfspraul>
at least a good challenge for me, I need to find and build alternative sales and marketing channels
<wolfspraul>
in your world view, if the NanoNote had sold 5000 units to date, would you also say 'acceptance is low'?
<wolfspraul>
I think the key challenge for copyleft harwdare is to build strong sales and marketing channels.
<wolfspraul>
not lost interest in Ingenic at all, why?
<wolfspraul>
we hat a lot of strange judging from the armchair again :-)
<wolfspraul>
I will probably demand 100k USD or 200k USD from Ingenic to sponsor the next Ingenic product, and they may very well never pay that. But that's their problem :-) I'm super 'interested' in their sponsorship :-)
<wolfspraul>
just saying what's going through my mind lately
<wolfspraul>
for mechanical, there are many ways that are at the same time:
<wolfspraul>
a) very professional and modern looking, very innovative (on whatever angle)
<wolfspraul>
b) well suited for low volume (will always be important for copyleft hardware, even if we have some high volume products)
<wolfspraul>
c) cheap
<wolfspraul>
that's the combination we need to find
<wolfspraul>
I would argue that what we have for m1 does quite well, on b) especially. c) can be worked on. a) is debatable but most people who see the case truly like it. I think it's a winner.
<wolfspraul>
there may be other mechanical approaches that satisfy a) b) and c), for example milling aluminum
<wolfspraul>
we just need to experiment more, as we did with m1
<wolfspraul>
simply looking at some random 'industry price lists' with high price tags doesn't get us any further I think. My goal is to make great cases that satisfy a) b) and c), at the same time.
<wolfspraul>
sounds like sie is going into a direction of simple breakout board
<wolfspraul>
the biggest weakness of their entire approach is on the software side
<wolfspraul>
basically they are incapable of even the smallest software development
<wolfspraul>
that means they can only make boards that work with the vendor BSP as they get it
<wolfspraul>
and the vendor BSP may or may not go upstream, in most cases it won't (at least not in its original form, and after it has been modified they won't be able to get the upstream version to run on their board again)
<wolfspraul>
I tried to bridge this but failed.
<wolfspraul>
I am not interested in random boards being manually soldered together to work with a vendor BSP for a while. At least for them it doesn't matter how long the boards work because they will break soon, the students think at most in categories of 1 year, then they throw their project away as well.
<wolfspraul>
the shortcomings kristianpaul found with his SIE will surely never be fixed :-)
<wolfspraul>
that's not my approach at all, it's not how I think you can build products or a brand
<wolfspraul>
sparkfun has tons of interesting boards then, far better than the current board they soldered together
<wolfspraul>
kristianpaul: sorry that the SIE I sold you is a dead-end product
<wolfspraul>
I really hate that normally, but that was the choice of the designers and I am unable to correct it. An expensive lesson for me to learn "don't try to help academia" :-)
<wolfspraul>
should not have done it, would have saved me 10-20k USD and one dead-end development less in my history
<kristianpaul>
dead, no pronlem :) also you dint sold it actually i remenber... some expenses were shared actually
<wolfspraul>
oh you got one of Carlos early prototypes?
<wolfspraul>
the main failure with SIE is that bugs are not fixed
<wolfspraul>
that's where a company and a project part ways, imho
<wolfspraul>
bugs have to be fixed, next version improves. combine this with smart marketing and you may build a business.
<wolfspraul>
but this is different. bugs are just ignored, removed, argued away. not good.
<wolfspraul>
of course they actually just need boards for students to play with, so if you think about their needs, it all makes sense
<wolfspraul>
they are perfectly fine with boards that are buggy, break apart after a few months. 99% of the students will throw away their project and any related material (such as a board) on the same day they get the exam back that concludes that segment of their studies
<kristianpaul>
no no, run 3 i think..
<wolfspraul>
so for m1, what I like is how we improve everywhere, constantly. that needs to continue. I am already tring to max out what I can improve for rc4 :-)
<wolfspraul>
I wish we could throw more resources at improvements, but it depends on sales revenue, that's ok.
<kristianpaul>
roh: (apppleinsider) i think we found a nice aplication for your CNC ;)
<wolfspraul>
kristianpaul: can you still build new software for your sie?
<kristianpaul>
wolfspraul: abosultelly
<kristianpaul>
acutally i think i'll find a case for it and use it as signal generator
<wolfspraul>
which build environment do you use? (openwrt?) which kernel?
<kristianpaul>
openwrt same as nanonote
<kristianpaul>
it jsut works
<wolfspraul>
are there any patches we could feed back?
<wolfspraul>
ok that's good to hear!
<kristianpaul>
well, i dont have i2c and have to disable keyboard
<wolfspraul>
definitely give us feedback if something breaks
<kristianpaul>
haha ok
<wolfspraul>
well that's what I care about. software power.
<kristianpaul>
patches, yes, dont carlos buged you with patches before leave the list? ;-)
<kristianpaul>
i think zrafa was working on i2c driver, not sure
<wolfspraul>
some patches I saw were of such crazy quality that I don't think anybody cleaned them up yet
<kristianpaul>
hehe sure
<wolfspraul>
I mean those are not 'patches' really
<kristianpaul>
lol
<kristianpaul>
ok
<wolfspraul>
you can also uuencode a binary that you got to run somehow :-)
<wolfspraul>
I was thinking about the price of m1 recently, and how we can bring it down.
<kristianpaul>
please :)
<wolfspraul>
I don't think I can touch the 499 USD price of the current product, it just has all these expensive things in it that add up.
<wolfspraul>
and if I remove them I make it much less valuable for a non-technical user
<wolfspraul>
so I thought maybe we make a new board, just the bare chips on it that will still allow you to reuse (and develop) 90+% of the software
<wolfspraul>
no case, lots of ios, maybe geared towards dsp or rf as well. Sebastien mentioned some ideas at some time, but I need to ping his brain more.
<wolfspraul>
no accessories, no keyboard, remote, camera, anything.
<wolfspraul>
just price down
<wolfspraul>
and still achieve full software compatibility with m1 the video synthesizer (with all its bells and whistles making it hard to go below 499 usd fast)
<wolfspraul>
just thinking
<kristianpaul>
bare chips still the expensives ones, if i recal correctly chips related to very specific VJ stuff are not that expensive
<rjeffr>
wolfspraul that is an interesting approach
<wolfspraul>
maybe something like xue
<kristianpaul>
or i'm wrong?
<wolfspraul>
well of course we would leave the fpga, nor, ddr ram, etc.
<wolfspraul>
but what is the point of the board?
<wolfspraul>
1) low price, shave off every USD we can
<wolfspraul>
no accessories, not even a power supply maybe
<akiwiguy>
a reasonably cheap hacking platform?
<kristianpaul>
it seems
<rjeffries>
depned on what price point you can hit
<wolfspraul>
2) stay 100% compatible with the m1, that's the key to get you into a position where you have a strong environment around you, rather than getting stuck in a moon landscape
<kristianpaul>
not vey specific, but i wonder if some people prefer something with unlimited posibilites or a specific turnkey product
<wolfspraul>
3) open the door for some future Milkymist products, by means of expansion header, ios, etc.
<rjeffries>
wolfspraul some of your cost are ports that only are interesting for vjay use case
<akiwiguy>
i prefer something that i can do a lot of things with personally, even if it takes a bit of work to set up
<kristianpaul>
please please dont forget add at least two dedicated pins for clock in the next expansion header if posible !!!
<akiwiguy>
rather than a solution that just works but only does a few things
<wolfspraul>
kristianpaul: no worries, your advice will be taken, guaranteed
<rjeffries>
before you do this you need to figure out who will make USB work as a general USB and IMO make the 8:10 port usable and acessible from the edge of the board
<wolfspraul>
akiwiguy: of course that's what we all work towards with our crazy investments into 'upstream' and keep it all easily buildable from source etc.
<akiwiguy>
yeah
<rjeffries>
but removing the items you mention does not rip out a lot of cost does it?
<wolfspraul>
I think about use case
<wolfspraul>
and it adds up
<rjeffries>
keyboard is $5 camera is maybe $25 p/w is another $5 max
<wolfspraul>
the product I am making now works for non-technical users
<akiwiguy>
i think, if you had a board with just the FPGA and necessary stuff
<akiwiguy>
with no extras
<wolfspraul>
I can whole-heartedly recommend it to any non-technical user because all they need is in the box.
<akiwiguy>
and expansion headers for people to hack up addons for it to make it do what they want
<wolfspraul>
akiwiguy: well there are tons of boards, and we easily end up in the arena of subsidized marketing boards
<rjeffries>
ok. but if you can only hit $399 selling price with adequate margin to keep your children fed, the market is prolly still quite limited
<akiwiguy>
you'd sell heaps of them
<wolfspraul>
rjeffries: you and your market :-) I do enjoy it with coffee though :-)
<wolfspraul>
akiwiguy: no, would not. you can try though :-)
<akiwiguy>
but there isnt much with the same amount of power of the Milkymist SoC
<rjeffries>
akiwiguy be careful. not sure I see "heapsOf users who wnat an FPGA computer
<akiwiguy>
i mean
<wolfspraul>
the devil, and all value, is only in the details
<akiwiguy>
when the Linux kernel is running well on Milkymist
<rjeffries>
wolfspraul I sometimes wonder what you are thinking. by the way you said market you meant margin
<wolfspraul>
that's why a discussion of people who are just guessing is worthless
<kristianpaul>
rjeffries: (USB) it could, just we need a proper OHCI implementation, any volunteering around it? :-)
<akiwiguy>
it would be a great hacking platform for us Linux guys
<wolfspraul>
zoom in, try it out, and find out about the hidden elephant
<rjeffries>
you know very well that ther emust be a delta between what it costs you to build and what people pay you
<akiwiguy>
and the ability to just reflash your entire processor is a bonus xD
<wolfspraul>
akiwiguy: do you still want to buy your NanoNote?
<rjeffries>
kristianpaul you know damnd well I am not a coder.
<akiwiguy>
of course I od
<akiwiguy>
do*
<wolfspraul>
great!
<akiwiguy>
just no money :/
<wolfspraul>
oops
<wolfspraul>
:-)
<akiwiguy>
xD
<kristianpaul>
rjeffries: but you seems good with social skill, you can catch a developer in the wild :)
<akiwiguy>
my dad wants me to write some printing software for him in VB.net
<akiwiguy>
and if I do that I get $100nzd
<wolfspraul>
that's a start
<rjeffries>
one never knows, does one
<akiwiguy>
but ewww visual basic is horrible
<wolfspraul>
do it, you learn about real customer needs
<wolfspraul>
yep
<wolfspraul>
REAL CUSTOMER NEEDS
<rjeffries>
visual nbasic is just another language
<rjeffries>
no biggie
<wolfspraul>
some people never get there, but it's actually a rewarding experience
<wolfspraul>
they do have strange priorities, I can tell you :-)
<rjeffries>
actaully it is reasonably powerful. no my cuppa, but nothing to sneer about
<akiwiguy>
i have had a look at it, and trying to get printing to work in it will be hell
<akiwiguy>
I use VB a lot myself
<wolfspraul>
my first job was similar, a summer job to work on a melanoma (skin cancer) database for a doctor
<wolfspraul>
got 100 deutschmark for 3 months work
<akiwiguy>
when i have to write something fast
<akiwiguy>
but it's not a very nice language
<kristianpaul>
thats important akiwiguy (customer needs)m we tend to dream and dream, and inpose our desires on sofyware and forgot that we MUST solve a need
<wolfspraul>
serve your customer, make him happy
<akiwiguy>
worse than Java, IMO
<wolfspraul>
then sell him the upgrade to the language you prefer :-)
<wolfspraul>
(it's your dad here, but the point is always the same)
<kristianpaul>
:D
<akiwiguy>
Yeah...
<rjeffries>
screw it code it in VB and take the money and then do what you like
<akiwiguy>
yeah
<akiwiguy>
but it'll be a lot of work
<akiwiguy>
because there are no printer libraries
<akiwiguy>
i cant just tell it to print this on this position on the page
<kristianpaul>
wolfspraul: (xue) when you said that you mean formfactor/pinout and also the imaging part?
<wolfspraul>
probably not
<wolfspraul>
I really don't know
<akiwiguy>
if i could do that the code would have been done last month xD
<wolfspraul>
maybe we can make a list of 'things' one could theoretically hookup to Milkymist
<wolfspraul>
it would be long though
<wolfspraul>
then we see that we can make a board that keeps the path to those 'things' open
<kristianpaul>
well if there is free pinout :)
<wolfspraul>
image sensor would be one of them, surely
<wolfspraul>
one of many though
<wolfspraul>
I am just thinking now, I can easily spend a lot more energy into m1.
<wolfspraul>
and improve it
<wolfspraul>
but if we want to build a crazy cheap hacker board, that won't work because it conflicts with some needs (and valuations) of non-technical users that buy m1
<kristianpaul>
MMU ;-) ?
<wolfspraul>
that's a software feature
<wolfspraul>
if we build a milkymist hacker board, its value can only come from the milkymist software stack running on it, imho
<rjeffries>
until someone adds MMU MM is not a viable Linux platform. period. nevermind that lekernel is not interetsed
<wolfspraul>
"viable Linux platform"
<kristianpaul>
:-)
<wolfspraul>
let's just say you don't like it without mmu
<wolfspraul>
but you would never buy one anyway, so why care? :-)
<kristianpaul>
is getting good shape rjeffries , you can run uclinuc, you can have a toolchain easilly, not bad
<kristianpaul>
also openwrt is a strong basis it seems
<wolfspraul>
also improvements in gcc (c++) or llvm badly needed
<wolfspraul>
dynamic linking
<rjeffries>
kristianpaul for teh true belivers yes. but the lack of MMU will lead to any number of randowm crashes. this is not rocket science
<wolfspraul>
but one by one, progress is really good lately
<wolfspraul>
kristianpaul: how often is your m1 crashing?
<kristianpaul>
rjeffries: buy it , use it, crash it and complaing with us later :-)
<kristianpaul>
wolfspraul: not often
<wolfspraul>
which root causes do you suspect?
<rjeffries>
that is notr the relevant question wolfspraul, and you know that. MM1 is running a very constraind set of apps. with linux you run all sorts of weird stuff, some of it with well hidden bugs
<kristianpaul>
he, well in my case i had been the resposible for some crahses in part, as my HDL coding techniques are improving :)
<rjeffries>
and you know I am not complaining. I am pointing to facts.
<wolfspraul>
"no mmu" is a fact. "not a viable Linux platform" is not a fact.
<wolfspraul>
I estimate 80% of what you say is not a fact, but opinions built upon facts.
<kristianpaul>
wolfspraul: also i cant tell to much as i just run too very basic rtems stuff, flickernoise annd rendreing is a unknow world for me
<wolfspraul>
but it's your good right to have opinions, of course...
<rjeffries>
wolfspraul should one assume all of your opinions are facts? ;)
<kristianpaul>
also i think all those suposed crashed, are not well handled expenscion from the cpu, wishbone... you can wonder all the empties around that :)
<rjeffries>
you will get to find out if an FPGA based realtively expensive linux platform finds enough customers
<rjeffries>
anyway, enough of this.
<akiwiguy>
I just had an idea.
<wolfspraul>
you forgot "not viable" in there
<wolfspraul>
"relatively expensive not viable linux platform"
<wolfspraul>
I do enjoy my coffee today
<akiwiguy>
When Milkymist can run Linux well enough, why not a "netbook" type device, like a larger NanoNote, with the Milkymist SoC?
<wolfspraul>
Yunnan, yummie :-)
<akiwiguy>
I would certainly buy one.
<wolfspraul>
what kind of use case do you want on a netbook?
<akiwiguy>
Web browsing, word processing, video playback
<wolfspraul>
so the problem is most people want high performance
<wolfspraul>
even when you say 'word processing', mayby you want to embed pictures from your camera?
<kristianpaul>
lynx, vi and mplayer ;) (on busybox ;-D)
<wolfspraul>
those pictures can be 10mb big?
<akiwiguy>
i dont have a camera xD
<wolfspraul>
you want to 'quickly' adjust contrast & brightness, or do other 'auto' picture manipulation
<wolfspraul>
well I'm just saying
<wolfspraul>
many things are possible
<akiwiguy>
yeah, i get what you mean
<wolfspraul>
I don't understand the netbook use case, so I'm asking.
<wolfspraul>
on my notebook, I want power
<wolfspraul>
memory, cpu
<wolfspraul>
cannot get enough
<wolfspraul>
I want to be able to work with images and videos faster.
<wolfspraul>
even presentations/talks
<wolfspraul>
the NanoNote on the other hand is a pocket computer
<larsc>
and you want the battery to last longer than 10 minutes ;)
<wolfspraul>
I don't need high-performance, since i would simply move those things to my notebook.
<akiwiguy>
All I use my netbook for is web browsing, word processing, video and audio playback and ssh
<wolfspraul>
so I can move all sorts of small interesting computing tasks to the nanonote.
<kristianpaul>
(battery) oh please :)
<kristianpaul>
want a netbook with that qi pixel display :-)
<akiwiguy>
My current netbook has a standard lcd and I can read it in the sun fine xD
<akiwiguy>
I walk around with this thing at school all say doing all my class work on it
<akiwiguy>
and I am quite often outside in the sun working on it
<rjeffries>
kristianpaul for wahtever reasons, that interesting qi-pixek display seems to still not be designed in to anything significant. I do not know why.
<akiwiguy>
personally i see no need for an e-ink display or anything similar when existing already in use tech works fine
<kristianpaul>
rjeffries: well, i worth that my battery will long last
<rjeffries>
I carry a decentt little smartphone (not iPhone) with a 4-in. display. it has a nice slide out keyboard, nice screen. it works.
<wolfspraul>
rjeffries: maybe that is because their strategy is to come out with outlandish announcements and vaporware to attract (more) investors?
<rjeffries>
akiwiguy with e.g. eink monochrome display one gets two weeks on one battery charge for a book reader e,g, Kindle
<akiwiguy>
Yeah...
<akiwiguy>
For stuff like an ebook reader, then an e-ink is good.
<wolfspraul>
akiwiguy: yes, screens are getting much better recently in terms of sunlight readability. I need to compare some...
<rjeffries>
wolfspraul? well, I paid $149 with my carrier. the little company who made my device is called Motorola. You may have heard of them.
<kristianpaul>
milkymist ebook? :)
<akiwiguy>
For a netbook or similar, there's no point because you can't refresh them very fast
<rjeffries>
kristianpaul you are cracking me up
<akiwiguy>
and they'd be useless for anything but reading
<kristianpaul>
rjeffries: hahah ;)
<wolfspraul>
rjeffries: I meant the "interesting qi-pixel display"
<rjeffries>
akiwiguy google qi pixel display  thay have solved those problems in an elegant fashion
<wolfspraul>
:-)
<wolfspraul>
you are double cracking me up
<wolfspraul>
didn't you just say above that "the interesting qi-pixel display seems to still not be designed in to anything significant"
<rjeffries>
i am so totally lost
<wolfspraul>
and then you recommend to google it because they have "solved those problems in an elegant fashion"?
<wolfspraul>
maybe you pick one of your two arguments?
<rjeffries>
it has not found its market. I do not know why. maybe you do. the gal behind it is a very smart puppy an dthe technolgy is good
<rjeffries>
wolfspraul the technology works and works well, it has not been commercialized sucessful. ok
<wolfspraul>
you probably never met Mary-Lou, and it sounds like you never used one of their 'good' technology either? then how do you know it's good?
<wolfspraul>
have you used one of those super screens?
<akiwiguy>
their website is not loading
<rjeffries>
wolfspraul people I trust have
<wolfspraul>
rjeffries: so you have not
<wolfspraul>
that seems to be a fact
<akiwiguy>
i'm getting a blank page
<akiwiguy>
and the wikipedia page is unhelpful
<wolfspraul>
akiwiguy: it's vaporware. one word is enough.
<akiwiguy>
heh
<wolfspraul>
if seems your netbook maker has "solved this problem in an elegant fashion"
<wolfspraul>
rjeffries: I won't ask whether you bought and tried a Notion Ink yet...
<wolfspraul>
it's amazing how much money you can make fooling naive investors though, I have to say
<rjeffries>
wolfspraul you have a style that is different than mine
<wolfspraul>
there's always someone who wants to believe
<rjeffries>
let's agree we do not think the same and leave it at that. ;)
<wolfspraul>
rjeffries: yes indeed. very different. unfortunately in the computer industry many companies work with announcements, in different ways.
<wolfspraul>
sometimes to asses demand
<wolfspraul>
sometimes to fool investors (ah, to get them to invest to then hopefully make that announcement dream come true)
<wolfspraul>
oh definitely, please! Not the same, yes.
<rjeffries>
you are  asmart guy. I respect that. You offer some very sage opinions, but also get out in the weeds
<wolfspraul>
just I thought you like facts so much
<wolfspraul>
so the fact is that you never used a pixel qi screen yourself yet you are saying it is 'good technology' and 'solved a problem in an elegant fashion'
<kristianpaul>
goes for a nice evening Tea
<rjeffries>
you can drop the condescending attitude
<GitHub194>
[milkymist/gps-sdr-testing] missing overrun condition for the counter - Cristian Paul Peñaranda Rojas
<GitHub194>
[milkymist/gps-sdr-testing] namuru related bios commands WIP - Cristian Paul Peñaranda Rojas
<wolfspraul>
rjeffries: read it after your work break if you like. this is a hardware project. you are very good at criticizing others and that is appreciated and valued. and I know you are serious.
<wolfspraul>
but sometimes you have to take criticism too. Now, if you start with your duino boards, you will probably find that in hardware, the only thing that matters is to try something out in physical reality.
<wolfspraul>
seriously, that is the #1 #1
<wolfspraul>
_every time_, you buy a chip, because you read about some great feature X
<wolfspraul>
after you actually try it, you dive in, you find out 'ooops'. 'yes, they implemented X, but with the following caveat: ...'
<wolfspraul>
every time. 100%. guaranteed.
<wolfspraul>
so a lot of the experienced people here simply work features backwards. have you tried it? does it work? if yes: feature exists. if no: we know nothing until we tried
<kristianpaul>
who dont love caveats ;-)
<wolfspraul>
that's my experience from years of doing hardware now, and shared by many I know who are as real in this field as I am
<wolfspraul>
kristianpaul: would you agree with my assessment?
<wolfspraul>
when Ingenic comes out with a new chip, the 'feature list' is more a wishlist. THey 'think' that's what the chip should be able to do. They will remove features from the feature list as the customer complaints come in.
<kristianpaul>
wolfspraul: yes i do, i already had experienced that on my work too, not making hardware but integrate systems is always fun :)
<wolfspraul>
that's how the industry works (exaggerated in China but it's the same principle everywhere)
<kristianpaul>
security system*
<wolfspraul>
so complain about condescending or not, yes, Pixel Qi is ugly vaporware and needs to be labeled as such so that well meaning people in this channel can form their own opinion. After they have seen 2 opposing ones :-)
<wolfspraul>
I think one reason the hardware industry is so full of features that don't work once you try in practice is because the feedback loop is so slow.
<wolfspraul>
so a manager at some company may be desperate, and just get the feature in even with crippling limitations, he can save his job a few more months, or maybe get transferred to another department before the sales numbers come in. ("so low? why?")
<wolfspraul>
the feedback loop is many months typically
<wolfspraul>
that grows the problem unless you have a lot of experienced people everywhere who approach these many months of 'wishful thinking' (based on statements) with the attitude "at least 50% of this won't work anyway"
<wolfspraul>
but it's a dangerous development if we disconnect from what most people will happily use and what will be effective for them. we become like a sect in the mountains.
<wolfspraul>
by now the split is so big (say between GNU mailman and mailchimp), that I believe it cannot be reconciled ever
<wolfspraul>
people on neither side even care, actually :-)
<kristianpaul>
i was about to said that :)
<wolfspraul>
yeah we just gotta be careful to not pad on our own shoulders too hard...
<wolfspraul>
I won't go and fix those pipermail bugs either.
<wolfspraul>
kristianpaul: if Qi would make use of 'evil' tools like mailchimp.com, what would you think about that?
<wpwrak>
(cost-down m1) call is Phuenix ? ;-) oh, and i'd drop the NOR as well. as i understand things, nothing it does in M1 requires is to be NOR. a serial flash would do just fine, at probably a tiny fraction of the cost. (requires a bit of development effort, though)
<kristianpaul>
well.. i will doubt that copyleft way they claim soo hard ;)
<kristianpaul>
s/soo/so
<wolfspraul>
wpwrak: drop nor is one of the big questions, yes
<kristianpaul>
wpwrak: (serial flash) acutally a board from cern uses same s6 and serial flash
<kristianpaul>
design is there, just is altium, and i havent figure out how run rhe viewer in linux..
<wolfspraul>
kristianpaul: don't understand you. If Qi would use tools like mailchimp you would find Qi less authentic/credible?
<wolfspraul>
so my concern about dropping nor is... software compatibility :-)
<wolfspraul>
I still want to be able to build one image, ideally one bitstream, to run on all boards, all the way back to the first milkymist one rc1
<kristianpaul>
wolfspraul: well, it depends, if i consider there is a vps somehwere been ignored,
<wolfspraul>
if we can achieve that, then there is even value in the switch because our design and platform would be more flexible
<kristianpaul>
wolfspraul: of course that cost (vps/dedicated machine)
<wolfspraul>
vps? don't understand again
<wolfspraul>
would like like Qi to use mailchimp or not?
<wolfspraul>
(I don't want to, no worries. but I am curious about your thinking)
<kristianpaul>
NO :)
<wolfspraul>
ok
<wolfspraul>
thanks
<wolfspraul>
:-)
<kristianpaul>
wolfspraul: i host my own server too, and when i ran out money well, i should consider use githiub for host my page, but the i'll regret my self after 3 years of work to achieve that aparent autnomy :)
<wolfspraul>
so I am totally relaxed about nor vs serial flash, but I think it's an important decision that we need to make carefully
<wolfspraul>
unless we don't care that our platform disintegrates into a bunch of incompatible boards
<kristianpaul>
hum..
<wolfspraul>
I want to be able to build, from source, images for all boards I ever sold. and the maintenance and testing overhead of that should be as low as possible.
<kristianpaul>
thats true (incompatible boards), considering different bitstream bios support..
<wpwrak>
grmbl. a week worth of backlog in just about one hour. still ~5% from the bottom, according to the scroll bar ...
<wolfspraul>
and all mostly meaningless blurbs, sorry about that...
<wolfspraul>
the NOR vs. spi is a good topic though, I'll wait until you caught up
<larsc>
stop reading the backlogs in here long time ago ;)
<kristianpaul>
larsc: not all backlog is blurb
<wolfspraul>
I also read backlogs only sporadically, once a month maybe
<kristianpaul>
well, i really like backlog from wolfspraul and wpwrak discussion some days in the morning
<wolfspraul>
every minute reading = one minute less coding. Man I hope I can get back to coding one day...
<larsc>
kristianpaul: thats true. but the signal to noise ratio can get low at times
<kristianpaul>
may be is time to stop doing that :)
<wolfspraul>
yes but now I'm waiting for Werner and spi vs. nor :-)
<wolfspraul>
that one is very interesting to me
<larsc>
wolfspraul: i hope i can get away from it one day ;)
<wolfspraul>
from coding?
<larsc>
yes
<wolfspraul>
wait until you want back :-)
<wolfspraul>
computers fight fair
<wolfspraul>
we swap. you do sourcing, I do coding.
<larsc>
hehe
<larsc>
i'll start at my first 9-5 coding job in two months. lets see how that goes
<wolfspraul>
you will do well. stay for 2 years at least, my advice.
<wolfspraul>
that'll be the hardest part for you :-)
<wolfspraul>
congratulations btw for getting that job! it's always exciting to be around new people, I think.
<larsc>
yeah, i guess it will be quite interesting. at least in the beginning
<kristianpaul>
(new people) indeed, after two years or so will be boring tought imho
<kristianpaul>
well, at least is what i can said from my current job
<wolfspraul>
wpwrak: caught up?
<wolfspraul>
is there any electrical reason why m1 cannot support usb-otg ?
<wolfspraul>
(lars just brought his up in a PM)
<wolfspraul>
I think it's usb host right now, and if you solder some passive component somewhere you can turn it into a USB client
<wolfspraul>
but what about otg? aside from the missing IC design support, I would think
<larsc>
otg uses a different connector
<wolfspraul>
but that's only mechanical I think
<larsc>
that connector has also an additional pin
<larsc>
the id pin, which is used to detect what kind of device is attached
<larsc>
i think you can support at least a subset of otg with a 'normal' transceiver
<wolfspraul>
yes it's a very good point. I don't know what the smartest way forward is with the Micrel transceiver we have right now. needs more study.
<wolfspraul>
I do remember Sebastien saying at some point that it is possible to support USB client mode by adding a passive part somewhere.
<wolfspraul>
of course then it's hard-coded to client :-)
<wolfspraul>
not exactly the type of switching we have in mind for otg
<wolfspraul>
and the micrel receiver we have only support full-speed (12mbps), not sure whether that is a problem. and then the work in the SoC (IC design), no idea.
<wolfspraul>
I also just notice the diagrams seems to suggest a surge protection, wondering whether we have that... (this is unrelated to otg of course, just noticed)
<wolfspraul>
ok, we need to keep this on the to-be-researched list :-)
<wolfspraul>
is anybody against bumping andrew's nyan cat on silicon to the top of the news?
<wolfspraul>
if not I'll try. he just uploaded better pictures from a better run.
<Artyom>
kristianpaul: I would check at first access to Namuru-registers. What about adding couple of test registers to which you can write and couple registers from wich you can read what was written previously?
<Artyom>
And also I want to ask about array "const int prn_code[38]". Did you take values for it from osgps or from namuru documentation (osgps and namuru use different values).
<wpwrak>
(back from a nap. continuing with the backlog. still some ~3% from the bottom ... just passed my last comment on the backlog)
<wpwrak>
catch-up complete !! ;-)
<wolfspraul>
:-)
<wolfspraul>
and I'm just back from running, good
<wolfspraul>
Lars brought up the interesting otg subject, that's something I will try to understand better at some point
<wolfspraul>
but let's talk about nor vs. spi first
<wolfspraul>
that one is really important I think, right now
<wpwrak>
(nyan cat) maybe for the future, a brief "highlights" section could be interesting. say, three items of insterest, be it because they mark important progress or because they're just unusual, pick a ~100 pixel image and use it as a "button". that way, you could place such "off-topic" things prominently without creating confusion
<wolfspraul>
so let's first remove some myths about the nor chip: it is easy to source, and it costs 10.50 USD for me right now
<wolfspraul>
you find thousands of it in stock at Arrows, though not at digikey (where you can still order it in some quantity though)
<wolfspraul>
so it's not an obscure chip, and instead of 'expensive', let's just say 10.50 USD and then compare...
<wpwrak>
(nyan can) oh, and it's s/Nyon/Nyan/ ;-) nyon is a nice little place between lausanne and geneve where they have a big open-air concert event every year. sort of a swiss woodstock ;-)
<wolfspraul>
the pros are: speed (what speed? boot speed?) execute-in-place?
<wpwrak>
according to lekernel, EIP isn't used
<wolfspraul>
current Milkymist is 'compatible' with it? what does that impact exactly? bitstream? bios? rtems?
<wolfspraul>
if we make another milkymist board with an SPI flash, how can we achieve binary software compatibility across both boards?
<wpwrak>
EIP would have been my #1 concern. if it was used, then the replacement may be more difficult (e.g., you'd at least need more RAM)
<wolfspraul>
one of my goals is that whatever I produce, I wnat to be able to maintain/support the software on it for good / forever
<wpwrak>
how big is the NOR again ?
<wolfspraul>
so I like to 'switch', but we must switch in such a way that later will not increase our software maintenance burden
<wolfspraul>
32 MiB
<wolfspraul>
if we achieve that, then we make the Milkymist platform more powerful/flexible, and that's always good
<wolfspraul>
but if we don't achieve it, we create fragmentation and that's the worst we need, imho
<wolfspraul>
that's my #1 concern, really
<wpwrak>
i wouldn't make binary compatibility a requirement. it's not something you can control anyway. what you can control is a process that makes building the set of binaries you need painless
<wolfspraul>
fine, but you understand my point
<wolfspraul>
the less we work on this, think about it, the more fragmentation
<wpwrak>
if you can achieve binary compatibility, great. if not, you take it in stride
<wolfspraul>
and that will kill Milkymist in the long run
<wolfspraul>
first we define it as a worthwhile goal
<wpwrak>
sounds fair
<wolfspraul>
and since we are designing the boards, there always should be a chance to signal hardware differences in some way
<wolfspraul>
if we don't try, it will fragment very fast
<wolfspraul>
and in 5 years we have a lot of boards and the software will be a mess
<wpwrak>
USD 10.50 is for which quantity ?
<wolfspraul>
for rc3 I bought 90 maybe
<wolfspraul>
or 95
<wpwrak>
so that's the ~100 units price
<wolfspraul>
at Chinese/Taiwanese distributors the volume discounts are not as steep as at US distributors
<wolfspraul>
Chinese work harder :-)
<wolfspraul>
so as you go down in volume, the price goes up, but not that fast
<wpwrak>
yeah, they only care about the 1M+ discounts ;-)
<wolfspraul>
I believe for rc2 I may have paid a little more
<wolfspraul>
wait, I check. should be in the wiki too.
<wolfspraul>
no, also 10.50 USD
<wolfspraul>
at digikey it's 11.xx for ca. 500
<wolfspraul>
but not in stock
<wolfspraul>
so anyway, I just want to avoid we have this 'expensive' as our only argument, and rather compare real numbers
<wolfspraul>
this chip is from a big series of NOR chips, so even if this one goes away I doubt the entire series goes away. I don't know how much a smaller or larger one would be.
<wolfspraul>
the nor chips were just sold from Intel to Micron I believe. something like that.
<wolfspraul>
what I don't like about it is that it is physically big
<wolfspraul>
I don't know how an SPI flash would compare in size
<wolfspraul>
wpwrak: so now let's compare :-)
<wolfspraul>
what is the spi alternative? what are the pros and cons?
<wolfspraul>
speed, price, size, binary or other platform compatibility, availability
<wolfspraul>
is that the end of our comparison already? :-)
<wolfspraul>
not enough pros?
<wolfspraul>
if a 16mb flash is already 4.73, I would think the 32mb flash costs 7-8 USD?
<wpwrak>
size is a function of pins and capacity
<wolfspraul>
so the cost savings are in the 3-4 USD range
<wpwrak>
if 16 MB is at the top end of the range, it would be more than 2x. but i don't know how reliable digi-key are as an information source here. they generally don't have a lot of memory.
<wpwrak>
(size) so at some point, if you need very high capacity, the die size dominates the total size. if your die can be small, the number of pins does.
<wpwrak>
but i'd try to go for something more radical anyway. boot a minimum loader, then haul the rest in from uSD
<wolfspraul>
you can search for 'strataflash' at digikey, that's the name of the series
<wpwrak>
this is non-trivial, because you'd also have to "upgrade" the FPGA. but once you've solved that, you never have to go back to this kind of issues :)
<wolfspraul>
then numonyx only
<wolfspraul>
in general they seem quite well stocked for this series
<wpwrak>
yes, all "non-stock", but all in stock ;-))
<wolfspraul>
yeah. they show all these funny numbers under 'quantity available'
<wpwrak>
anyway, i'd just fix the boot process for good. reduce external dependencies. go with the simplest serial flash that can do the job, and only keep the absolute minimum "core" there. ideally, you'd never have to change it.
<wpwrak>
move all the things that can change, break, etc., into something nice and easy, like uSD
<wolfspraul>
wait
<wpwrak>
and yes, buy ten of each type of holders they have at digi-key and test which one actually works ;-)
<wolfspraul>
I understand
<wolfspraul>
first I look into this nor chip now
<wolfspraul>
I try to understand it
<wolfspraul>
in general at digikey the 16mib or 32mib variants seem available, but there are a lot of speed variants there it becomes 'call' only
<wolfspraul>
for the faster speeds (85ns)
<wpwrak>
Megabits or MegaBytes ?
<wolfspraul>
I feel 'relatively' safe about this nor chip
<wolfspraul>
mib = megabytes
<wolfspraul>
I think it's a big series and must be used in high volume products all over.
<wolfspraul>
on the other hand it's clear that compared to say 'smartphones', those chips are crazy expensive and selling in crazy limited numbers
<wpwrak>
yeah, maybe PCs still boot form NOR
<wolfspraul>
also embedded, it's a big world
<wolfspraul>
Intel sold it to Micron, not sure what that means
<wolfspraul>
but my point is - this is not a rare/exotic chip that makes me worry right now, even though several people try to tell me that
<wolfspraul>
I just don't see evidence
<wpwrak>
(nyan cat) btw, his new results are too perfect. the old one showed some chemistry going awry. the new ones just look digitally generated :)
<wolfspraul>
it's clear that the price point of such chips is 'high' compared to the super high volume chips nowadays
<wolfspraul>
but you could extend that argument to the spi flash as well
<wolfspraul>
wpwrak: well, he asked me to use the new pics and that's fine by me. I think for the casual browser those pice are nice.
<wpwrak>
yeah, it's price point, size, layout complexity (the chip needs data and address lines)
<wpwrak>
(nyan) yeah, just kidding. the results are amazing
<wolfspraul>
so what is the bottom line now?
<wolfspraul>
we first try to make the boot process ready for larger diversity?
<wolfspraul>
but we are not actively looking at spi flash now because nor is just fine?
<wpwrak>
i think a NOR->SPI flash change should come with a generalization of the boot process. dunno the technical details but it sounds like a problem that can be solved, particularly given that lekernel already knows FPGA internals so well :)
<wolfspraul>
I highly doubt he sees that as an interesting task at this time, with seemingly hundreds of more interesting ones in the pipeline
<wpwrak>
if you try to map the current NOR 1:1 to SPI, you seem to force yourself into a corner of the existing product range
<wolfspraul>
you mean the spi flash product range?
<wpwrak>
i'm not saying that he'd have to execute it :) but i'm sure he'd share his knowledge
<wolfspraul>
which one do you see 'in the middle' there?
<wolfspraul>
I feel no need/pressure for this switch now, my main interest is to prepare/guide it in such a way that strengthens and will not fragment the platform
<wolfspraul>
for m1 I don't need it
<wpwrak>
in the middle of the chip range ? dunno. a small number of MB. you shouldn't need much.
<wpwrak>
(M1) agreed. it's a relatively invasive change. for M1 you want to stabilize, then spin off (an) improved model(s)
<wolfspraul>
but strangely enough a log of developers who never source much are telling me those nor flash are hard to source :-)
<wpwrak>
no point in creating an eternal construction site
<wolfspraul>
which makes me wonder is this just an argument because they are more familiar with spi flash?
<wpwrak>
oh, i remember NOR sourcing fun at openmoko. compared to a lot of other things, they have a pretty high bitchiness rank :)
<wolfspraul>
yes, and it's not sure for me now that a switch to spi flash would even be an improvement, I am trying to understand what the improvement would be.
<wolfspraul>
what exactly do you remember there?
<wolfspraul>
I am already sure by now that many developers will be more familiar with SPI flash, reasonable or not.
<wpwrak>
first of all, not all NOR are created alike. so you have to be careful about the specs. control signals, bus type, internal structure, etc. depends a bit on what features you need, of course.
<wolfspraul>
not that I think the typical hardware folks are big risk or innovation seekers either :-) unlike us/me here :-)
<wolfspraul>
I also heard those 'horror stories' but at the time I was too clueless to dig in.
<wolfspraul>
it may well have been just myths and ghosts, mixed with a lot of incompetence
<wolfspraul>
and a quick look and order on digikey would have solved the problem
<wolfspraul>
quite possible, as you may have to admit :-)
<wpwrak>
naw, there were real. i did the research for the NOR chip ;-)
<wolfspraul>
then what were the problems?
<wolfspraul>
we switched from one manufacturer to another?
<wpwrak>
and of course, FIC sourcing then replaced the one i found with a slightly different one. and guess what couldn't be found then ? ;-))
<wolfspraul>
always same manufacturer?
<wpwrak>
no no, that was the addition of "unbrickability" NOR in gta02, coming from the brickable gta01
<wolfspraul>
yes I know
<wolfspraul>
the very reason for adding that chip smells 'over-engineering'
<wolfspraul>
but that's a different subject
<wolfspraul>
but what were the technical problems now?
<wolfspraul>
you chose one?
<wolfspraul>
which manufacturer/model?
<wolfspraul>
and then they changed? to what?
<wolfspraul>
and then what?
<wpwrak>
i need to dig out the old mails. parameters that matter there include the write protection mechanism, the bus type, internal structure (not all blocks have the same size), volatage domains (some are even dual-voltage)
<wolfspraul>
yes ok
<wolfspraul>
but then you chose one, right?
<wolfspraul>
of course there are many parameters
<wolfspraul>
my history/experience with nor flash starts with the micron/numonyx one on m1, and so far, so good
<wpwrak>
also, some of the NORs get around a lot. company X makes them, then they get bought by Y, the NORs get transferred into joint-venture Z, and so on. so there are a lot fewer actual chips on the market than you'd think if you just collect names
<wolfspraul>
sounds like hearsay
<wolfspraul>
I mean that is exactly what happened in the intel->micron case, but it was super transparent and easy to understand and follow
<wolfspraul>
in fact Intel published PDFs that detailed every tiny bit of the move in such a way that you would think they are training monkeys
<wpwrak>
i chose one. then FIC sourcing picked a different one. smaller and i think some small technical details changed as well (but that wasn't a major issue). and, unlike mine, it was hard to source ;-)
<wolfspraul>
so that nobody in the supply chain is scared if the label suddenly looks a little different :-)
<wolfspraul>
yes!
<wolfspraul>
but that's not a nor problem
<wolfspraul>
I still don't know manufacturer names
<wpwrak>
intel usually have great documentation
<wolfspraul>
they switched manufacturer?
<wolfspraul>
there are not that many fabs that make such chips
<wpwrak>
ah yes, NOR documentation is also something. some of the stuff you can only figure out by reading 2-3 data sheets from competitors
<wolfspraul>
I can only say that lots of people tell me "nor on m1 is bad"
<wolfspraul>
so I take full responsibility for dismissing that, which is not that great.
<wolfspraul>
but so far, it's fine
<wolfspraul>
that's also unspecific again
<wolfspraul>
wait let me check our nor datasheet...
<wolfspraul>
there seems to be a lot of nor hatred out there ;-)
<wolfspraul>
there must be hundreds of part numbers there, it's still loading more...
<wpwrak>
;-))
<wolfspraul>
plus if it is true that Micron doesn't release anything but fancy marketing datasheets for Ron, then that's a big argument against it, in my book
<wpwrak>
yes, there are tons of different NORs. and it's oh so easy to pick one that's obscure.
<wolfspraul>
(sorry Ron :-))
<wolfspraul>
but I don't want to jump to conclusions
<wpwrak>
i take a dim view of "you can have our data sheets, but you have to beg for them" companies
<wolfspraul>
wait one by one
<wolfspraul>
still researching
<wolfspraul>
I don't like a 404 link in our bom anyway
<wolfspraul>
ok we have a backup copy on downloads, well done by Adam, even without the help of dsv...
<wolfspraul>
I will link to that first
<wpwrak>
if they give the data sheet to anyone who asks, they've merely invented a process with a step that wasted my and their time. i don't like it if people presume my time is theirs to waste.
<wpwrak>
if they filter who gets access and who not, they've just added an element of unreliability to the process, particularly with a distributed environment like ours
<wolfspraul>
oh very easy. that means the datasheet doesn't exist.
<wolfspraul>
I will never ask.
<wolfspraul>
copyleft hardware is about speed
<wolfspraul>
my typing speed
<wolfspraul>
no fickle human in between
<wolfspraul>
for now we can point to the backup we have on downloads
<wpwrak>
yeah, i pretty much treat them like this, too. registration/approval/other nonsense required -> goes right down to the bottom of the pile
<wolfspraul>
but chips without datasheets are not suited for copyleft hardware, so if that's micron's new policy (after the takeover from Intel), that will mean their stuff will probably get designed out of our products, sooner or later
<wolfspraul>
oh. with 'datasheet' of course I mean a full and honest datasheet
<wpwrak>
*grin*
<wolfspraul>
so - first I fix the links to our backup
<wolfspraul>
but that would be a serious argument against the nor chip, again in my book
<wolfspraul>
yes, the datasheet I can download from all** after so and so many links is exactly the same one we have on downloads
<wolfspraul>
so that's good
<wolfspraul>
we are still in possession of a full 66-page datasheet for the nor chip on m1
<wolfspraul>
it's on downloads, and various ee porn sites on the web
<wolfspraul>
but for future nor chips from Micron that doesn't look too good...
<LunaVorax_>
hi everyone !
<wolfspraul>
now, let's do it right, Werner style
<LunaVorax_>
Werner ?
<wolfspraul>
Micron lists a total of 791 part numbers in their parallel nor flash catalog
<wolfspraul>
of which 611 are in 'Production'
<wolfspraul>
147 are End of Life
<wolfspraul>
5 are Sampling
<wolfspraul>
28 are "Contact Factory"
<wpwrak>
LunaVorax_ ? :)
<LunaVorax_>
What/Who is Werner ? You wpwrak ?
<wolfspraul>
yes, totals up to 791
<wpwrak>
LunaVorax_: yup
<wolfspraul>
where is ours?
<wpwrak>
wolfspraul: you're more pedantic than I am. i don't think i ever checked that the numbers of items they find add up ;-)
<LunaVorax_>
How is qi-hw going ? I haven't received any newsletter for a long time
<wolfspraul>
It's in "Production"! Yippie.
<wolfspraul>
LunaVorax_: glad to hear you are experiencing some sort of cold turkey...
<wolfspraul>
LunaVorax_: soon you can buy a Milkymist One for 499 USD + shipping
<wolfspraul>
how about that?
<wolfspraul>
I think I tried to sell it to you already, but you went silent :-)
<LunaVorax_>
Haha yeah
<LunaVorax_>
I don't have any 500$ in my pockets right now
<wolfspraul>
wpwrak: well ok. I still feel fairly safe about the sourcing situation of that chip.
<wolfspraul>
that's ok, just saying. there are many ways how you can help, and your presence here is already nice.
<wolfspraul>
just spread the word then - Milkymist! :-)
<LunaVorax_>
And I'm still devoting my self to the Nanonote for now, trying ot code a GMenu2x alternative in SDL
<wolfspraul>
oh wow
<wolfspraul>
that's great
<wolfspraul>
the NanoNote is our pocket computer, and until we can come up with a better pocket computer it will stay there
<LunaVorax_>
I don't know, it started as a copycat of Windows 8
<wolfspraul>
try to do it super low-resource
<wolfspraul>
fast and very little memory
<LunaVorax_>
Yes I will, but keep in mind that I'm a beginner
<wolfspraul>
we are all
<wolfspraul>
you are in the right club here
<wolfspraul>
absolute beginners
<LunaVorax_>
Haha
<wolfspraul>
seriously
<LunaVorax_>
I always felt at home at #qi-hardware ;)
<wolfspraul>
wpwrak: if the datasheet of the nor flash went mia, that's bad
<wolfspraul>
we still have copies and there are enough on the web and that will be safe forever, but it's not good for the future
<wolfspraul>
but before coming to that conclusion I need to check on the micron site a bit more, or, god forbid, email them for a statement
<wpwrak>
yeah, data sheets "disappearing" isn't nice
<wolfspraul>
well
<wolfspraul>
the division was sold
<wpwrak>
alas, happens with those mergers and acquisitions
<wolfspraul>
correct
<wolfspraul>
there may be a new strategy around IP, documentation, etc. new managers. it's ok with me.
<wolfspraul>
it just may mean that we take our business elsewhere.
<wpwrak>
maybe it just pops up again with a new part number and a new company logo
<wolfspraul>
end of story
<wolfspraul>
no
<wolfspraul>
that has already happened
<wolfspraul>
and that is why the datasheet is gone now
<wolfspraul>
404
<wpwrak>
the URL would of course change :)
<wolfspraul>
no
<wolfspraul>
you don't understand
<wolfspraul>
it was already branched out at the Intel times
<wolfspraul>
but then it got swallowed up by Micron
<wolfspraul>
so there is a nice redirect from numonyx.com to micron.com, but it ends in a nice Micron 404 page
<wolfspraul>
it could be an oversight, but I doubt it
<wolfspraul>
micron just has a number of 'technical briefs' in which they explain all their greatness to you
<wolfspraul>
all the many battles that they fought for you, etc. etc.
<wolfspraul>
I need to look a bit more, no conclusion yet.
<wolfspraul>
I'll fix the links first.
<wolfspraul>
first have to take care of our little beauty m1
<wpwrak>
marketing to decision-makers with an MBA :)
<wolfspraul>
oh yes
<wolfspraul>
"we chose that Micron technology, because ..."
<wolfspraul>
the only thing the engineers can hope for then is to remember the paycheck, and wonder whether it's enough in damage compensation
<wolfspraul>
but this is how our world functions, Micron also just needs to survive...
<wolfspraul>
so I have no gripes with them, but I will remove their chips from my products :-)
<wolfspraul>
which they will not worry about given my sales volume...
<wolfspraul>
looks like 4 megabytes or even 8 megabytes...
<wolfspraul>
you wouldn't want to limit the growth of the bitstream that way
<wolfspraul>
the 8:10 will cause a lot of pain, so we better plan several of them, so that one can be completely done and mounted/inserted on the production line, and ideally never touched
<wolfspraul>
whereas the second one is meant for user interaction
<wpwrak>
bitstream plus a simple uSD loader
<wolfspraul>
2 bitstreams? loader from scratch/u-boot/qi/linux?
<wpwrak>
maybe with the ability to read files from, say, FAT, by name
<wolfspraul>
:-)
<wpwrak>
naw, for fallback/recover/etc., just pick an alternative set from the uSD card
<wolfspraul>
won't work if you screw up the bitstream
<wolfspraul>
(or the bootloader, but I would expect more risky development to happen on the bistream side)
<wpwrak>
e.g., do if (no_magic_key_pressed) { if (can_load("M1-FIRST.BOO") boot(); } while (!can_load("M1-SECOND.BOO")); boot();
<wolfspraul>
risky in the sense that it won't boot
<wolfspraul>
ok so we say developer have jtag anyway, can unbrick
<wpwrak>
i would look for a way to replace the bitstream
<wpwrak>
that's probably the tricky bit
<wolfspraul>
huh? don't understand
<wpwrak>
partial reconfiguration :)
<wpwrak>
or maybe you can even do full reconfiguration
<wolfspraul>
I'm practical
<wolfspraul>
I think some fpgas also support configuration from your beloved card now
<wolfspraul>
:-)
<wolfspraul>
but again, I'm practial and don't just want to discuss for discussion's sake
<wolfspraul>
so what works for m1, now, as the next step... that's what I wonder about
<wolfspraul>
need to check whether the s-6 supports anything from sd
<wpwrak>
i don't think you want to change that in M1. for M1, I'd say, stabilize, bring the software into shape. then do an M2 where all the little nuisances of M1 are fixed. M2 would be the right place for that kind of boot architecture redesign.
<wpwrak>
for the Phuenix, you said that you'd want to drop lots of things. what parts of M1 would you want to keep ?
<wpwrak>
(M2) or Phuenix. if they're not effectively the same ;-)
<wolfspraul>
LunaVorax_: how can we make development for the NanoNote for you more fun?
<wolfspraul>
what is Phuenix?
<wolfspraul>
wpwrak: I don't want to make the boot/nor change at all
<wpwrak>
a mixture of phoenix and Xue ;-)
<wolfspraul>
but one thing I can imagine is that we make a little board, or a few, to test some of those things or to develop them early
<wpwrak>
i.e., your cost-down M1
<wolfspraul>
ah no, definitely not
<wolfspraul>
I don't see it there
<wolfspraul>
for me this is about strengthening the Milkymist platform
<wpwrak>
(test board) yes, that's the right approach. small steps :)
<wolfspraul>
so I think we could make some test boards
<wolfspraul>
with the goal of going in that direction while maintaining compatibility with what has been done before
<wolfspraul>
because this kind of change will impact different parts, software, tools, etc.
<LunaVorax_>
wolfspraul, invent a machine that can transfer all the programming books directly to my head ;)
<wpwrak>
yes, of course. you can also get rid of jtag for good if you want :)
<wolfspraul>
that's a job for Werner, clearly
<wolfspraul>
he can invent such a machine
<LunaVorax_>
wolfspraul, more seriously, I have trouble compiling a single SDL hello world under the Nanonote
<wolfspraul>
maybe xiangfu can team up with you if you need help. we should have some nice little hello world apps as starting points for people.
<LunaVorax_>
I'll run a compile again in a few minutes to check what kind of errors I get
<wpwrak>
LunaVorax_: the machine will be for free. but the special headache pills will cost you ;-)
<LunaVorax_>
haha
<wolfspraul>
including a wiki page that walks you through step by step how to bring them live and add your own code to them...
<LunaVorax_>
wolfspraul, yes that should definitely be needed
<LunaVorax_>
wolfspraul, it reminds me the problem with the GP2X Wiz. It's aimed at game developers, but the wiki, docs and toolkit is insanely chaotic
<wolfspraul>
well
<wolfspraul>
I cannot, or should not, raise any sort of expectations on your side that our wiki is or will be better
<wolfspraul>
a clean wiki is terribly hard
<wolfspraul>
needs some people to basically make that their contribution to the project to just clean clean clean
<wpwrak>
wolfspraul: anyway, what peripherals would the cost-down M1 keep ? USB host ? uSD ? Ether ? audio in ? audio out ? midi ? dmx ? video in ? video out ? LEDs ? :)
<wolfspraul>
that's not an m1
<wolfspraul>
it's a way to broaden the Milkymist platform, bring it to new use cases/developers, without breaking compatibility
<wpwrak>
alright, the Phuenix ;-)
<wolfspraul>
I have no idea what it would keep or add
<wpwrak>
ok :)
<wolfspraul>
Sebastien floatet the idea of a Milkymist board 'around' dsp/rf/io one time
<wolfspraul>
so he may have been thinking about some ideas
<wolfspraul>
don't know details
<wpwrak>
byw, you could probably also trim down the M1 without losing too much. e.g., drop MIDI, Ether, maybe also DMX. use USB for MIDI and host communication. maybe there's also USB-to-DMX
<wpwrak>
strike the maybe :)
<wpwrak>
expensive, though
<wolfspraul>
don't understand
<wolfspraul>
that's not realistic, you seem to forget that m1 works today, as a product
<wolfspraul>
who will develop all these usb-to-anything dreams?
<wpwrak>
yes, but you want to cost-down, right ?
<wolfspraul>
why would it be cheaper? which prices are you comparing?
<wpwrak>
well, MIDI-USB is already there (in linux)
<wolfspraul>
in Linux...
<wolfspraul>
again
<wolfspraul>
M1 is a product that works _today_
<wolfspraul>
I cannot compare what works today with something that is just imagination
<wpwrak>
the cost-down M1 would be tomorrow :)
<wolfspraul>
that's not cost down
<wolfspraul>
it's causing insane trouble and costs everywhere
<wpwrak>
why ?
<wolfspraul>
well, I just told you some examples
<wolfspraul>
all those usb-to-anything simply won't work
<wolfspraul>
or you start coding today? :-)
<wolfspraul>
case changes
<wolfspraul>
box changes
<wolfspraul>
that's not cost down really
<wolfspraul>
and then we need external parts
<wolfspraul>
source from where?
<wolfspraul>
at what price?
<wolfspraul>
the end result may even be clunkier than an integrated connector
<wolfspraul>
no no
<wolfspraul>
horrible :-)
<wpwrak>
you want proper usb support anyway. "we don't support this" gets boring after a while
<wolfspraul>
let's leave m1 as is, cost down inside yes
<wolfspraul>
I can only look at and compare realistic options
<wolfspraul>
what I talked about is another board, completely separate from the video synthesizer product
<wpwrak>
you only need external parts in case they're needed. not everyone needs MIDI. and a lot of today's MIDI is already USB. not everyone needs DMX.
<wolfspraul>
that board could meet a number of goals at the same time
<wolfspraul>
but MIDI and DMX are in the product now, keeping them costs me maybe a few USD / unit
<wpwrak>
DMX would probably be part of an expensive installation anyway. so, make it part of the cost of the $$$$ lighting equipment, not part of the $$ milkymist
<wolfspraul>
removing them would cost tens of thousands of USD
<wolfspraul>
argh no. well. those things simply won't happen.
<wolfspraul>
we are making a product and will polish it, software updates, marketing, etc.
<wolfspraul>
remove jtag-serial
<wolfspraul>
maybe switch from vga to dvi-i
<wolfspraul>
those are all controlled improvements
<wolfspraul>
update the video decoder chip
<wolfspraul>
if we switch from vga to dvi-i we of course will include adapter cables in the box
<wolfspraul>
and then software updates, and more software updates
<wpwrak>
you say you want to be "compatible". what does this mean ? will the Phuenix run flickernoise ?
<wolfspraul>
and hopefully 2 years later it's a much more powerful box
<wolfspraul>
well, we are defining the purpose of this board now
<wolfspraul>
so the answer depends on that
<wolfspraul>
oh btw, a Milkymist Two might do things like xilinx -7 or altera, ddr3, add a touchpanel on the top, etc.
<wpwrak>
(USB-centric M1) i think this should be a product evolution step. remove excess "fat". that is, if your market analysis shows this will help you. (financially or in terms of spreading the word)
<wolfspraul>
but that's after we sell a few thousand Milkymist One
<wolfspraul>
once you put a product out on the market, like a video synthesizer, it's about evolution not revolution, imho
<wolfspraul>
you cannot remove dmx as the next step, that's crazy
<wolfspraul>
makes no economic sense
<wolfspraul>
you are just building a channel and doing marketing so people value those features
<wolfspraul>
and you are delivering updates to them that use those features more and more
<wpwrak>
(M1-USB) i.e., if people bark at the USD 500 price tag and you can't bring the per unit cost down much with the present hardware design, trimming off non-essential bits may help to reach, say USD 300.
<wolfspraul>
you overestimate the cost of the dmx and midi parts
<wolfspraul>
it doesn't add up to much at all
<wpwrak>
you can check if people actually use DMX. if 99% don't care about it, you can safely drop it. particularly if you're nice and make sure an alternative exists
<wolfspraul>
if I cost-down the acrylic case and make it in China that alone will bring me 10 times more than all those parts together
<wolfspraul>
no no
<wolfspraul>
now it's about marketing those features, not removing them
<wolfspraul>
it will stay for at least 2 years
<wolfspraul>
:-)
<wolfspraul>
let's make that 3, or 5
<wolfspraul>
see above
<wolfspraul>
dvi, yes
<wpwrak>
of course, you will have those who complain about not having DMX in the box. but you seem to have a lot of people complaining about the USD 500 price tag today. that's overwhelmingly the #1 reaction
<wolfspraul>
higher-performance fpga, yes
<wolfspraul>
ddr3, maybe _add_ a touchscreen, yes
<wolfspraul>
for the m1 product, think in that direction
<wpwrak>
(acrylic) yes, that one's pricy :)
<wolfspraul>
who is complaining about 500 USD?
<wolfspraul>
developers
<wpwrak>
do you have a calculation what each feature effectively costs (BOM-wise) ?
<wolfspraul>
well the bom is just there, easy to add up
<wpwrak>
yes, maybe the VJs will just eat the cost
<wolfspraul>
no they will demand a high-performance product that they know and that works out of the box
<wolfspraul>
if that's the case they will happily spend 1000 USD
<wolfspraul>
or whatever it takes
<wolfspraul>
and if that's not the case, they will not buy no matter how cheap it is
<wolfspraul>
that's how most people value products :-)
<wolfspraul>
to reach those, we need higher performance in some key areas
<wolfspraul>
MORE features, not less
<wolfspraul>
what I'm thinking about now is a second board
<wolfspraul>
something new
<wolfspraul>
pcba only
<wolfspraul>
no case
<wolfspraul>
CHEAP
<wolfspraul>
purpose? hardware hacking
<wpwrak>
you may also want to consider the amateur market. people who want cool video effects at their student party.
<wolfspraul>
even most of those need a _working_ product above all
<wolfspraul>
that's why they all have Macs nowadays
<wolfspraul>
not known to be the cheapest notebook maker
<wpwrak>
oh, sure. i consider "working" as a given. like linux and proper USB. that's stuff you have to do anyway, so there's not point in discussing it from an "what if" angle.
<wolfspraul>
you see my point is a totally separate thing
<wpwrak>
what do we call that second board ?
<wolfspraul>
none of the m1 buyers would even compare with that 'thing'
<wolfspraul>
no case, as a starter
<wolfspraul>
no accessories
<wpwrak>
no, give it a name first
<wpwrak>
any name ;-)
<wpwrak>
you don't like Phuenix ? ;-)
<wolfspraul>
pretty crazy :-)
<wolfspraul>
Phuenix
<wolfspraul>
I'm fine with that
<wolfspraul>
:-)
<wpwrak>
kewl. nobody will get the inside joke, but that's fine ;-)
<wolfspraul>
hardly pronouncable for Americans, I can tell you already
<wolfspraul>
after the Milkymist shock this will kill Jon
<wpwrak>
rhymes with "fun" :)
<wolfspraul>
EVERY american will think this is a bad typo
<wolfspraul>
anyway, OK
<wolfspraul>
so Phuenix
<wolfspraul>
see the goal is totally different from m1, m2, m3
<wolfspraul>
that's a video synthesizer
<wolfspraul>
we hope to reach out to non-technical people
<wpwrak>
ask the british what they think of the american's opinions on orthography ;-)
<wolfspraul>
we hope to make it the most powerful video synthesizer later, with hundreds of features
<wolfspraul>
there's certainly a lot it _could_ do
<wolfspraul>
video streaming etc.
<wolfspraul>
but as a product, and marketing message, we need to leave that untouched for a while
<wolfspraul>
it's a new brand
<wolfspraul>
you cannot sell a product and 6 months later disappear
<wpwrak>
so, Phuenix will be "compatible". what does that mean ? what sort of applications are supposed to run (in a useful way) both on M1 and Phuenix ? "hello world" ? Flickernoise ?
<wolfspraul>
ok, so that's clera I think. my perspective on the line of video synthesizers
<wolfspraul>
they will also do cost-down, but without destroying the product
<wolfspraul>
now
<wolfspraul>
there's something missing
<wolfspraul>
hackers are complaining
<wolfspraul>
hackers may not like the all-inclusive accessories list
<wolfspraul>
they can even buy a power supply themselves
<wolfspraul>
they can solder DIP parts themselves
<wpwrak>
(Milkymist line) keeping that one is good. would indeed be crazy to drop it. there lies openmoko, rhymes with "madness" :)
<wolfspraul>
which compatibility exactly - good question
<wpwrak>
the accessories are largely a crutch to overcome the lack of drivers. you don't really need them in the long run.
<wolfspraul>
we can already see within the Milkymist One/Two/Three video synthesizer line, there could be challenges
<wolfspraul>
imagine an upgrade to xilinx-7, or a future altera-based Mx
<wolfspraul>
or ddr3
<wolfspraul>
all that should be introduced in a 'compatible' way
<wolfspraul>
or SPI flash
<wolfspraul>
but what is compatible exactly?
<wolfspraul>
we can always assume full source availability
<wolfspraul>
one sec bbiab
<wpwrak>
a technically halfway competent Vj will probably not want to use the accessories for long anyway. nice out of the box experience, then put them back into the box and connect serious equipment. and then they'll hit the driver problems ;-) but again, i expect all those to get fixed with time
<wolfspraul>
you tell me what you think it should be, on the Milkymist platform...
<wolfspraul>
I need to make the product work _NOW_, because I want to sell it _NOW_
<wolfspraul>
:-)
<wolfspraul>
so I don't want anybody to go through an experience like I did with buying 4 different keyboards
<wolfspraul>
or 10 different remote controls
<wolfspraul>
let's talk about Phuenix and compatibility, that's interesting
<wpwrak>
you want to sell it now and make it work as good as you can, given that constraint :)
<wolfspraul>
yes
<wolfspraul>
our users/buyers would want me to do that for them
<wpwrak>
Phuenix, let's start with the easy things. will it have USB host ? video out ?
<wpwrak>
(keyboards/remotes) dunno. the remote probably yes, because "generic" remotes often are quite different beasts. not sure about the keyboard. some will probably want a nationalized keyboard, with the layout they're familiar with. keyboard, even the rubber type, are usually easy to find. so it's not an item that really adds much value.
<wolfspraul>
very good, I just realize. We do indeed need to define something like "Milkymist Hardware Compatibility Requirements"
<wolfspraul>
like a list of things that a board needs to have in order to be 'milkymist compatible'
<wpwrak>
(kbd) and since you don't offer a choice of layouts, it becomes a (small) sales issue. because people will probably ask for their choice of layout and you'll have to turn them down.
<wpwrak>
yeah, "core platform" :)
<wpwrak>
FPGA with this or that capabilities, at least xxx bits of DRAM, etc. :)
<wolfspraul>
we can write whatever we want into those requirements, and refine them over time etc.
<wolfspraul>
but I think that'd be a start
<wpwrak>
since cost is a consideration, it would be good to have the BOM cost per subsystem. e.g., what does audio in cost, what audio out, what both together, how much for DMX, etc.
<wpwrak>
also, we should assume that M1 is mature by then, with proper linux drivers for all interfaces
<wolfspraul>
those are easy to identify immediately for me
<wolfspraul>
that's a total of 121 USD
<wolfspraul>
the total for the entire board is 190 I think
<wolfspraul>
DMX, let's see
<wpwrak>
DMX seems to cost USD 4 for connectors alone. they're also pesky through-hole parts
<wpwrak>
err no, USD 3
<wpwrak>
but there's probably more to it, in terms of circuit
<wolfspraul>
my estimate would be 5-8 USD for DMX
<wolfspraul>
dinner, bbiab
<wpwrak>
U4, U5, D6 through D13, J7, J8
<wpwrak>
and, unlike those expensive USB-DMX devices, no galvanic separation. may be an electrocution risk for M1.
<wolfspraul>
there is little reason to discuss dmx, because on m1 the video synthesizer line it will stay for good/the foreseeable future
<wolfspraul>
whereas on Phuenix, at least in my thinking, that's the last thing I can see there
<wpwrak>
your estimate of DMX BOM cost was good. 2*1.864+8*0.015+1.601+1.338 = USD 6.787
<wolfspraul>
ahh
<wolfspraul>
:-)
<wolfspraul>
it goes back to my bank account, you know :-)
<wolfspraul>
I'm not suicidal
<wolfspraul>
but seriously, on m1 it stays, and on Phuenix I totally cannot see it
<wolfspraul>
let me try to think through my main goals for Phuenix (proposals)
<wolfspraul>
cheap
<wolfspraul>
milkymist 'compatible (to be defined what that is - requirements)
<wolfspraul>
no accessories, no case
<wolfspraul>
opens up new development opportunities, new use cases (something that is not yet in m1)
<wolfspraul>
yeah, that's all
<wpwrak>
(Phuenix) i'd keep at least USB host and video out. add USB in. probably drop ether.
<wolfspraul>
comes back a little to Xue (without image sensor, remember in the last xue iteration the image sensor was already on a daughterboard)
<wolfspraul>
USB yes, definitely
<wolfspraul>
video-out, yes
<wolfspraul>
drop ether, hmm
<wolfspraul>
that requires improved usb :-)
<wpwrak>
you eventually want USB in anyway :)
<wolfspraul>
yes sure
<wolfspraul>
we think alike
<wolfspraul>
out with all this stuff
<wolfspraul>
super cost down
<wpwrak>
audio ? video in ?
<wolfspraul>
but it must be a way for the Milkymist platform to grow
<wolfspraul>
yeah well
<wolfspraul>
don't know
<wolfspraul>
Sebastien chose the video decoder (quite expensive) to get it to work fast
<wolfspraul>
I think theoretically the fpga might be able to do that too
<wolfspraul>
not sure what that means 'theoretically'
<wolfspraul>
audio maybe the same?
<wolfspraul>
can the fpga implement what the wolfson does now for 5 usd?
<wolfspraul>
if yes (theoretically), what does that mean?
<wolfspraul>
ac97 is a standard already...
<wolfspraul>
there's often a tradeoff between theoretical and practical to make...
<wolfspraul>
if we go with theoretically possible on too many things, the board may just be dead and unattractive
<wpwrak>
analog in substitution may be tricky. you need at least an ADC. and a fast general-purpose ADC may be more expensive than all those specialized chips. plus, you'd need serious signal processing, also to remove all the analog domain you problems you may create
<wpwrak>
you could drop the video out DAC ;-)
<wolfspraul>
well
<wolfspraul>
that's why we have to focus on something
<wolfspraul>
and why I like the focus of the m1 product/video synthesizer very much
<wolfspraul>
so this second board needs to be a calculated move
<wolfspraul>
retain some stuff, open up new interesting development fronts/opportunities
<wolfspraul>
just the right balance
<wolfspraul>
and cheap, no case, no accessories, I think those we agree on
<wolfspraul>
remove old interfaces, yes I fully agree
<wolfspraul>
dmx, midi, ethernet
<wolfspraul>
all out
<wolfspraul>
easy
<wolfspraul>
but then?
<wolfspraul>
usb otg? even high-speed?
<DocScrutinizer>
roh: ping
<wolfspraul>
how to interface with new chips, imaging sensors, rf chips, others?
<DocScrutinizer>
moin wolfganf
<DocScrutinizer>
moin wolfgang
<wpwrak>
high-speed is tricky ;-) but yes, desirable too
<wolfspraul>
remove video decoder? that may well be the end of any practically working video-in feature, for years or forever :-)
<DocScrutinizer>
moin werner
<wpwrak>
not sure if the fpga can do it. 480 MHz ...
<wolfspraul>
remove vga dac
<wolfspraul>
hmm
<wolfspraul>
digital out only?
<wpwrak>
ubb-vga style, discrete DAC ;-)
<wolfspraul>
wpwrak: well yes, you will have this question for every interface
<wolfspraul>
that's the tradeoff
<wolfspraul>
performance
<wolfspraul>
flexibility
<wolfspraul>
programmability
<wpwrak>
mompls. need to go afk for a bit
<wolfspraul>
that's why Phuenix above all needs good focus
<wolfspraul>
sure :-)
<wolfspraul>
no rush on this anyway...
<wolfspraul>
I'm already dwelling over it for a while
<wolfspraul>
milkymist, second step, but how, and where :-)
<wolfspraul>
DocScrutinizer: good morning!
<wolfspraul>
always nice to hear from you
<wolfspraul>
how are things going?
<wolfspraul>
I see you in heated discussions in other channels :-)
<DocScrutinizer>
sometimes
<DocScrutinizer>
:-D
<DocScrutinizer>
there are some things on this earth that make me either shout at people, or bitch like mad about what the original parents of that crap actually thought
<DocScrutinizer>
;-)
<DocScrutinizer>
recently I had a hard time not to treat Nokia's N950/harmattan combo in the microwave or with a sledgehammer
<DocScrutinizer>
now I've boxed and stowed away the N950 and my mood is way more relaxed again :-D
<DocScrutinizer>
honestly, a "security framework" that disallows root to write files to ~user/.ssh/* (for example). KTNXBY
<DocScrutinizer>
then when somebody comes to teach me I am stupid as I don't understand a device with a fat printing "DEVELOPER DEVICE, not for sale!" is actually not supposed to give full root access and in the end "it's not a unix workstation, it's a user device. You don't understand the concept of user device" then the debate starts gaining temperature
<DocScrutinizer>
anyway, busy for preparing for camp2011 which takes over in my life in 36h
<wolfspraul>
nice
<wolfspraul>
are you still in touch with Dieter?
<DocScrutinizer>
not at all
<wolfspraul>
is Dieter still active in osmocom?
<wolfspraul>
he, ok
<wolfspraul>
:-)
<DocScrutinizer>
don't know
<wolfspraul>
I was just wondering whether you all meet at the camp
<DocScrutinizer>
but I'm looking forward to meet Harald in radio village on camp
<wolfspraul>
laser is under 'scientific' I think :-)
<wolfspraul>
or 'entertainment'
<DocScrutinizer>
nope, sorry, I can't follow all that noise on this world anymore. Too much equally important and interesting stuff
<wolfspraul>
sure I was just kidding :-)
<wolfspraul>
no worries
<wolfspraul>
but yes we found the OpenLase project...
<wolfspraul>
maybe he will do the electrical design in KiCad, all software free and open etc. we see...
<DocScrutinizer>
I twice a year set 400.000 unread mails in my client to "status: read"
<wolfspraul>
that's marcan in this channel
<wolfspraul>
makes sense
<wolfspraul>
there's a lot of noise, I hope some of our stuff bubbles up over time. I'm patient.
<DocScrutinizer>
pretty annoying, and now even M infra just is down again, so I can't even get important updates regarding camp
<DocScrutinizer>
OM mail infra
<wolfspraul>
get off of those servers
<DocScrutinizer>
established it as my primary email over some 4 (?) years now
<DocScrutinizer>
that's the PTA with it
<DocScrutinizer>
PITA
<DocScrutinizer>
I hope I can move mail.openmoko.org one day I'm the only one still using it ;-P
<wolfspraul>
switch
<wolfspraul>
some good folks are holding up the wiki against spam flood, but I'm not sure when their willingness to mass-delete every day will be worn out
<DocScrutinizer>
or alternatively I'm happy to create some forwards on *my* mailserver for the other accounts :-D
<wolfspraul>
so the wiki is in the hands of 1-2 good fellas whom we gave admin rights
<wolfspraul>
but when they stop, I won't take over
<wolfspraul>
then we need to set the wiki to read-only most likely
<wolfspraul>
but not yet, they are still deleting, every day ;-)
<wolfspraul>
it would actually require a mediawiki update and captcha, but I doubt that will happen
<DocScrutinizer>
I don't worry about wii.om.org, it's mostly static now and probably somebody should eventually package it for download and local access
<wolfspraul>
it's not static, there is some edit activity still, and most importantly constant spam deletion
<wolfspraul>
if the spam deletion falls behind for 1 month or so, it's lost
<DocScrutinizer>
yeah
<DocScrutinizer>
my concern is joerg at om.org
<wolfspraul>
understood :-)
<wolfspraul>
switch
<wolfspraul>
are you the only user now?
<wolfspraul>
could be...
<DocScrutinizer>
mega pita to switch
<DocScrutinizer>
if I was the only user, it's easy, I just ask roh to change the MX record
<wolfspraul>
but there can't be many left, maybe some accouts, but real usage?
<DocScrutinizer>
yeah
<wolfspraul>
ok :-) well then...
<DocScrutinizer>
somebody could grep the mailer logs for actual polls
<wpwrak>
all my openmoko subscriptions are still on werner@openmoko.org, so things will all die together. anything else is now happily on almesberger.net
<wolfspraul>
to me looks like s-6 cannot directly configure from 8:10
<wolfspraul>
needs extra microcontrollers etc.
<wolfspraul>
that was obvious, but I wanted to check
<wolfspraul>
I've heard from fpgas support configure from 8:10 now
<wolfspraul>
wpwrak: I wanted to mention one thing about the Phuenix plans, regarding video-out
<wolfspraul>
so we have vga only now (analog), the DAC costs 3.50 USD
<wolfspraul>
so far so good
<wolfspraul>
we have already tentatively decided to upgrade m1 to a dvi-i connector asap
<wolfspraul>
which would leave the vga solution as is (same dac), and route the digital signals directly to the fpga, single-link, or if there are enough pins and routing space, even dual-link (most likely will not be utilized any time soon though)
<wolfspraul>
if rc3 sales are slow, maybe I will expedite this dvi-i idea and already include it in rc4
<wolfspraul>
but I don't hope rc3 sales are slow, and since the main goal is for m1 to not run out of stock anymore, we would probably not do dvi-i in rc4
<wolfspraul>
now.. whenever dvi-i is there, the door is open for the implementation of a digital video-output in the SoC
<wolfspraul>
'door open'
<wolfspraul>
once we get that working, and like performance, that would then allow us to go with a digital-only video-out solution on Phuenix
<wpwrak>
sounds good
<wolfspraul>
if we do it earlier (on Phuenix), that's risky because we are stacking multiple risks on top of each other
<wolfspraul>
and I rather keep our boards in a functioning/interesting state than turn them into development hell
<wpwrak>
you sound as if you wanted to start work on Phuenix tomorrow ;-)
<wolfspraul>
that would save us 3.50 USD on Phuenix and we could take the risk of going digital-only
<wolfspraul>
not start tomorrow, but start thinking today, yes
<wolfspraul>
I like this realization I had earlier "Milkymist Hardware Compatibility Requirements"
<wolfspraul>
that's absolutely great
<wolfspraul>
I will start to nag people about it :-)
<wpwrak>
ah, digital-only may not be so nice. VGA is still common.
<wpwrak>
but you can do cheap VGA, ubb-vga style
<wolfspraul>
I just wanted to explain the path that is already more or less planned on m1
<wolfspraul>
dvi-i, add digital, then develop in the SoC (who? no idea :-)), then have both as an option
<wolfspraul>
I will try to do this asap, even in rc4, but like I said the highest priority is to be always in stock
<wolfspraul>
and Adam is already working full-time, so we see when we get to it
<wolfspraul>
either rc4 or rc5
<wolfspraul>
:-)
<wolfspraul>
I also need to source new adapter cables then
<wolfspraul>
so digital video out is coming (first as an unimplemented option)
<wpwrak>
thanks to having an FPGA, that's even reasonably risk-free ;-)
<wolfspraul>
the choice of adcs/dacs on Phuenix will probably be tough
<wolfspraul>
well we got the easy questions answered
<wolfspraul>
remove dmx, midi, ether
<wolfspraul>
:-)
<wolfspraul>
who knows we can also just leave it there. even the same pcb, just leave some parts unpopulated.
<wolfspraul>
:-)
<wolfspraul>
maybe try to improve USB...
<wolfspraul>
integrate the atrf even? I'm up for it...
<wolfspraul>
what would it take to develop a DSL modem around Milkymist?
<wpwrak>
no idea what DSL needs
<wpwrak>
and i'd need CaTV anyway :)
<wolfspraul>
see your nor mails, interesting
<wolfspraul>
Atmel, hmm
<wolfspraul>
that's what we used in the end?
<wolfspraul>
I wasn't even aware Atmel did memory, but apparently they do. If that's what we had it may not have been the best choice of manufacturer (or unlucky, as you said, because things changed after the selection, which can always happen)
<wolfspraul>
the little I know about memory fabs is that they are prohibitely expensive, and huge investment leads to consolidation. so pick the biggest, if you can :-)
<wolfspraul>
which may or may not be the case for Atmel, but I haven't heard of them in that context before (searching now a bit)
<wolfspraul>
he. atmel.com doesn't list parallel flash at all anymore, at first glance.
<wolfspraul>
maybe they sold it
<DocScrutinizer>
wolfspraul: >>atben-atusb Combo  59,00 EUR \n  Elphel Eyesis  24,000 USD  <<
<DocScrutinizer>
WTF?
<wolfspraul>
yes! :-)
<wolfspraul>
wpwrak: you were right!
<wolfspraul>
DocScrutinizer: so what do you think about it?
<wolfspraul>
there's a GPL discount on that 24,000 USD price
<wolfspraul>
don't know how much, depends on your contribution back I think
<DocScrutinizer>
wolfspraul: I think it doesn't parse here
<wolfspraul>
it's an omnivision camera, click on the link next to it
<wolfspraul>
very cool thing, all GPL licensed
<DocScrutinizer>
either it has to be 59.00 or better 59.--, or it has to be 24,00
<wolfspraul>
price a little high, admittedly
<wolfspraul>
no the atben-atusb Combo is 59,00 EUR, the Elphel Eyesis sets you back 24,000 USD
<wolfspraul>
should I write it out in words maybe?
<wolfspraul>
both prices plus shipping
<DocScrutinizer>
you should stick to one locale, first instance
<DocScrutinizer>
either use . or , for decimal separator, but not both mixed
<wolfspraul>
I am listing shops/sources. The Elphel Eyesis ships from Salt Lake City, and only from there
<wolfspraul>
oh wait, checking
<wolfspraul>
believe it or not, that entire thing is GPL licensed
<wolfspraul>
all plans are open
<DocScrutinizer>
where "." means ", == thousands separator then, like in 24,000"
<wolfspraul>
electrical, mechanical, IC design, everything
<wolfspraul>
so you can build one and sell for 22,000 USD
<wolfspraul>
they are selling
<wolfspraul>
arguably the coolest piece of GPL hardware in the world, right now
<wolfspraul>
I think I make it 59.00, or just 59
<wolfspraul>
maybe just 59
<DocScrutinizer>
then, if you'd have used "29,999" I'd possibly not even had noticed it
<wolfspraul>
this was copy/pasted from Tuxbrain's shop, I didn't notice the inconsistency
<wolfspraul>
thanks a lot!
<wolfspraul>
now fixed :-)
<wpwrak>
i think the swiss got it right: . for separation from fractions, ' for thousands. so it would be 24'000.00, not nonsense like 24.000,00
<wpwrak>
or maybe the swiss use , anyway, doesn't matter, it's unambiguous ;-)
<wolfspraul>
I think it's good now, but you were totally right, before it was confusing
<wpwrak>
and now, out into the big blue room. shopping.
<DocScrutinizer>
alas elphel is next to illegible. Fixed linewraps of lines so long I need to scroll left/right for each one on my 1280 wide screen
<DocScrutinizer>
they are used to their panorama views on a 3 head system, I guess ;-D
<kristianpaul>
Artyom prn_code he, well, i think there is a typo somwhere
<kristianpaul>
and yes i have a general porpuse register to write and read, actually even a test write/read command too :)
<kristianpaul>
hopes that qi-bot will tell all this to Artyom when he showed up :)
<kristianpaul>
(touchpanel on the top) :-D
<wolfspraul>
kristianpaul: what do you think about the Phuenix plans so far?
<wolfspraul>
did you read anything where you mentally say "NO!"? :-)
<kristianpaul>
well, ethernet drop fire that NO on on mind
<wolfspraul>
he, I can understand
<kristianpaul>
but if you include atben, well :)
<wolfspraul>
because you know that works today, but the usb->ethernet plans are just wishful thinking
<kristianpaul>
i can force the switch
<kristianpaul>
very wishful indeed
<kristianpaul>
btw where came that idea of DSL modem?
<wolfspraul>
idea maybe a bit too much, but why not :-)
<wolfspraul>
but considering that you can get a dsl/wifi router for 20 usd, it's a tough proposition
<wolfspraul>
kristianpaul: the idea behind removing ethernet is the assumption that that board will also improve usb a lot, in whatever magical ways
<wolfspraul>
I agree with you that there's a reality gap somewhere in that thought
<wolfspraul>
so the Ethernet port may stay on, and can be removed when a real alternative exists :-)
<kristianpaul>
even tought i dont now.. look those usb to something cables coming from it.. soo messy :)
<kristianpaul>
at least a wireless solution works of the box
<kristianpaul>
we relly on ethernet for lot of stuff currently like netboot, patch uploads..
<wolfspraul>
yes I would like the idea of integrating ben-wpan a lot, let's see what Werner thinks
<wolfspraul>
we can also just go with my last idea up there, which is to keep the entire board the same, and just not populate some items like midi & dmx
<kristianpaul>
i read well (dont want to check backlog again) also jtag removal?
<wolfspraul>
not for developers of course
<kristianpaul>
ah ;)
<wolfspraul>
that's why I said the 'product' for users is one thing
<wolfspraul>
and it cannot remove dmx
<wolfspraul>
but it can remove jtag
<kristianpaul>
i tought wpwrak was about to suguest a good replace for htag :-)
<wolfspraul>
whereas Phuenix is on a different mission
<kristianpaul>
same board hum.. i tought you meant before xue like size?
<wolfspraul>
we are discussing :-)
<kristianpaul>
i mean more a rectangle? someething you can easilly hold with your hands may be?
<kristianpaul>
and also, you dint even talk about battery? :-)
<wolfspraul>
I am just thinking what makes sense, collecting feedback, thinking more
<kristianpaul>
sure sure
<wolfspraul>
I'd love to go mobile, for sure
<wolfspraul>
5V supply can be hacked into a mobile supply though, I would think
<wolfspraul>
since there's a lot of USB battery packs, solar chargers, etc.
<kristianpaul>
have its pack
<wolfspraul>
what do you have? can you give me a url or upload a picture?
<kristianpaul>
i use it to charge nanonote, as i something forgot to charge it and when need it is off
<kristianpaul>
the rf part what sebastien suguested, was TV* related?
<kristianpaul>
i dont remenber..
<wolfspraul>
output 5.5v, 600mA
<wolfspraul>
so you have a USB cable coming out of that?
<kristianpaul>
yes
<wolfspraul>
5.5v could work, a little high. 600mA is a little low, I wonder whether Phuenix could start with it :-)
<wolfspraul>
well, a lot of confusing thoughts now, let's see what bubbles up
<wolfspraul>
I will start to work a little on a Milkymist Hardware Compatibility doc
<wolfspraul>
I think that's a good thing
<kristianpaul>
indeed
<wolfspraul>
then it's not this open-ended 'anything' anymore
<wolfspraul>
where 'anything' unfortunately in most cases means 'infinite work'
<wolfspraul>
so it's more like 'nothing'
<wolfspraul>
that's all not good
<wolfspraul>
we should have a document, and clearly say what is inside of our scope, and what is outside of our scope
<wolfspraul>
and then the stuff inside is supported and maintained, and the stuff outside is not
<marcan>
wolfspraul: I will *definitely* do the design in kicad and all the software/firmware will be free/open, that much I'm sureof ;)
<kristianpaul>
about all USB is not just linux missing drivers also the current softusb is not even full OHCI if i recall correctly
<kristianpaul>
marcan: nice ! :)
<marcan>
I'm kind of in the middle of a relocation and job change though, so I don't expect any progress for a while ;)
<wolfspraul>
Sebastien needs to help us a little with that, mostly by telling us what is easy and what is hard to add/support/modify in the Milkymist SoC
<wolfspraul>
then we can include the easy items inside of the requirements scope, and the hard ones are outside
<wolfspraul>
marcan: oh sure, no offense :-) I am just super careful in over-promising, that only raises expectations and finally will make everybody feel things failed.
<wolfspraul>
if things are steady but going in the right direction, wow, that's awesome. that's the best.
<kristianpaul>
(Sebastien helps), oh sure, also that thinks like he is not going to code it, but at least point some sources and know caveats that he already known :)
<DocScrutinizer>
>>Cabstone Solar Not-Ladegerät mit integr. 5,5V 1000mAh Li-Po Akku ...<<
<wolfspraul>
we have a roadmap already in the milkymist wiki
<wolfspraul>
I just need help sorting things from easy to hard, then we have a start for our compatibility doc
<kristianpaul>
i had sees things appear in that roadmap the we're not written, so well a roadmap-like page i will say..
<kristianpaul>
s/sees/seen
<wolfspraul>
DocScrutinizer: you think they will provide 5.5V all the time?
<DocScrutinizer>
yes
<wolfspraul>
or is it slowly going down?
<DocScrutinizer>
no, step up converter
<DocScrutinizer>
LiIon is 3V7
<DocScrutinizer>
still :-D
<wolfspraul>
why 5.5 and not 5.0?
<wolfspraul>
isn't USB saying 4.75 to 5.25 ?
<DocScrutinizer>
hmm, maybe some weird devices work better with VBUS at upper specs
<kristianpaul>
5.5 because is intented to charge a battery i guess?
<wolfspraul>
kristianpaul: when you get a chance, can you measure which voltage how comes out of your pack?
<wolfspraul>
Li-ion is charged at 4.2 I think
<kristianpaul>
oh let me try right now, i have scope jut next to me :)
<DocScrutinizer>
seems like dedicated VBUS step-up converters always are specified for 5V5
<wolfspraul>
this just reminds me that on a closer look, I have sometimes seen power supply labels saying 5.0v, sometimes 5.5v
<wolfspraul>
wonder what's the story behind it
<DocScrutinizer>
cable loss etc?
<DocScrutinizer>
I'd guess some simple LiIon charger circuits run into trouble to charge cell up to 4.25..4.3V when input voltage drops to <5.0V
<wolfspraul>
ok but that's <5.0 now, not <5.5
<DocScrutinizer>
cable loss, connectors, et al
<wolfspraul>
since the usb spec says 4.75 to 5.25 I'm surprised that it seems high-volume supplies and packs just go for 5.5 :-)
<wolfspraul>
"a little more cannot hurt" philosophy?
<DocScrutinizer>
no idea where it came from, but that 5V5 figure is rather common
<kristianpaul>
fiding a way to probes reach usb connector
<wolfspraul>
whereever it originated, was that before or after the USB 5.0 spec?
<DocScrutinizer>
USB5.0 ? :-D
<wolfspraul>
in other words - was it done on purpose for some reason (like you say cable loss etc), or was it more like "ok, this happens to work for most USB devices as well, even though it's outside of the spec"
<DocScrutinizer>
NFC
<wolfspraul>
nfc?
<DocScrutinizer>
not the faintest clue
<wolfspraul>
ok
<wolfspraul>
will keep my ears open :-)
<wolfspraul>
I can ask our power supply vendor and see what they say...
<DocScrutinizer>
imagines Andy would join in to this debate
<kristianpaul>
5.3
<wolfspraul>
it's only a small difference but I am wondering where it comes from
<kristianpaul>
thats with no load, and from my cheap  generic multimeter
<wolfspraul>
kristianpaul: that's what I would have thought, at the end you get a little less than the 5.5v still
<kristianpaul>
now lets try with scope
<kristianpaul>
i want see over time..
<wolfspraul>
so maybe the supply provides 5.5v, on purpose, because they know they want to supply enough for a usb standard of 4.75-5.25 ...
<kristianpaul>
note that current charge is Half not full
<wolfspraul>
but according to DocScrutinizer that shouldn't matter
<wolfspraul>
DocScrutinizer: I've became careful, at least alert, of small differences like this one, yes :-)
<wolfspraul>
ignoring is always easy, I can ignore it a little later...
<DocScrutinizer>
yup
<wolfspraul>
until then I try to dig a little
<wolfspraul>
somehow I cannot imagine that the 5V5 became 'common' as you say before anything USB and was just 'made fit' later
<DocScrutinizer>
there's no use in "show me the usecase for making USB safe for arbitrary overvoltage" notion
<wolfspraul>
I would think it was done in full awareness of the USB spec
<wolfspraul>
I'm not talking about that
<DocScrutinizer>
I know
<wolfspraul>
I am curious about the difference, the reasons/origins.
<wolfspraul>
my guess would be it was designed like that
<DocScrutinizer>
just saying I've seen it frequently, so probably it's justified somehow
<wolfspraul>
to factor in cable loss, loss under load, etc.
<wolfspraul>
so that it stays within the USB range under normal conditions
<DocScrutinizer>
yup
<DocScrutinizer>
a little more is less of a problem that a itsy bit too low voltage
<DocScrutinizer>
than*
<wolfspraul>
so maybe a power supply whose label says 5.0V has the exact same 5V5 converter in it as the one that says 5.5V on the label...
<DocScrutinizer>
yes
<DocScrutinizer>
probably
<kristianpaul>
(upload patches) yes i know phounix is not about VJ but you get the upload stuff idea :)
<DocScrutinizer>
as bot will state +-10% anyway
<DocScrutinizer>
usually
<DocScrutinizer>
both*
<wolfspraul>
well
<wolfspraul>
:-)
<wolfspraul>
that would bring the one that says 5.5V to 6.05V then :-)
<wolfspraul>
making things worse
<DocScrutinizer>
no, as they can be rather sure the chip won't exceed 5V5
<wolfspraul>
if it's designed to factor in cable loss etc. the label should probably better just say 5.0V (in this case)
<wolfspraul>
yes but I was talking about the label
<wolfspraul>
if the label says 5.5V and +-10%, it'd be misleading
<DocScrutinizer>
or 5.5V+0-10%
<wolfspraul>
I'm sure I've never seen that :-)
<wolfspraul>
in fact most of the time no +- %
<DocScrutinizer>
rarely
<wolfspraul>
just 5.0 and 5.5, I do remember seeing both
<wolfspraul>
I think I mostly got it. For now we think it's always the same 5V5 converter inside...
<DocScrutinizer>
on components, esp capacitors you frequently find -20%+100%, or the other way round
<DocScrutinizer>
;-)
<DocScrutinizer>
-100% was nice though
<DocScrutinizer>
blowfuses also have such specs frequently
<DocScrutinizer>
all sorts of protective gear
<DocScrutinizer>
just keep in mind Vbat 4.30V to VBUS(low) 4.75V is pretty hard a living for simple circuitry
<DocScrutinizer>
so charging of a crappy mp3-player with a crappy usb charger might simply fail
<wolfspraul>
DocScrutinizer: you've seen the pics of some of the Chinese battery packs I took apart, right?
<wolfspraul>
a 12 V supply charging 3 li-ion in series, etc.
<wolfspraul>
you can always get something in...
<DocScrutinizer>
while no USB device except OM stuff is supposed to break on VBUS=6V
<wolfspraul>
it broke at 6V already?
<DocScrutinizer>
it wasn't specified to survive, so if it did it was to "good will" of chips
<wolfspraul>
what was it specified to survive and what should it have been specified to survive?
<wolfspraul>
(if you remember)
<kristianpaul>
lol a usb cable generate a lot of fun signals even when not connected no nothing.. well air :-)
<DocScrutinizer>
the critical part been pcf50633 which had either 5V5 or 6V0 ABS-MAX
<DocScrutinizer>
for the "should" ask Andy, he thought that'S well within USB specs
<wolfspraul>
sounds like 'should survive' should be at least 5.5V, if that's what the power supplies are even saying they may provide
<wolfspraul>
if not a bit more? 5.75? 6? you tell me...
<DocScrutinizer>
my design rules always been to design headroom in for random other equipment to fail without killing my stuff
<wolfspraul>
so if the power supplies already say 5.5, that makes it?
<DocScrutinizer>
no, not in my book
<DocScrutinizer>
depending on sitaution/case you are usually giving a 5%..100% headroom for increased safety. That's pretty much heuristics
<DocScrutinizer>
on power supplies I tend to be generous with headroom
<DocScrutinizer>
on mains 220V I'd not consider to build hardware to survive constant operation at >250V
<DocScrutinizer>
maybe 260
<kristianpaul>
scope measure same, peak of 5.3V
<DocScrutinizer>
usually you design hw so it fails gracefully and recovers with low to no effort, from overvoltage on supply
<DocScrutinizer>
headroom until overvoltage fries your OV-protective circuitry should be at least 300% I'd guess
<DocScrutinizer>
so if you connect a 110V device to 220V it blows fuse, and then it's "safe" up to at very least 1000V
<DocScrutinizer>
on Neo there's no fuse that blows, there's no chip that shuts down, on 6.0V. It simply *may* die irrecoverably
<DocScrutinizer>
and Andy thought he might proove something by applying 12V to *one* device and diagnosing "no blue smoke"
<wolfspraul>
ok understood
<wolfspraul>
thanks!
<DocScrutinizer>
he didn't even bother to check if the pcf50633 chip still completely works within specs after that test
<wolfspraul>
you would probably like the fuse+zener we have on m1 now :-)
<DocScrutinizer>
heh, great!
<wolfspraul>
probably :-)
<wolfspraul>
a varistor added on video-in as well
<wolfspraul>
as Werner thought dmx could be better protected too. and usb probably too :-)
<wolfspraul>
we see
<wolfspraul>
I think I got the 5.0v vs. 5.5v situation, thanks a lot!
<DocScrutinizer>
I'm pleased to see my ranting made a difference
<wpwrak>
back from shopping. phew narrowly escaped the invasion of the families with kids. was already too late to escape the housewives. sunday early morning (8-9 am) is perfect. then, only misfits like myself do their groceries ;-)
<wpwrak>
wolfspraul: (m1+wpan) sure, why not. external antenna ? RP-SMA-style, perhaps ? then you just need chip plus balun
<kristianpaul>
(wpan) and not forget at least footprint for increase transmit power :-)
<wpwrak>
(hw compatibility) maybe call it "Milkymist Hardware Family" ? "compatibility" sounds a little too strict
<wpwrak>
(5v5) maybe they just have bad load regulation. so you need some headroom to avoid dropping too far when the load suddenly jumps up
<wpwrak>
kristianpaul: increased tx power is a major design extension. needs to be built and tested first. there may be surprises.
<wpwrak>
kristianpaul: but yes, with the right chip, you'd even get antenna diversity. so you could, say, have an RP-SMA for an external antenna, plus an internal antenna
<wpwrak>
wolfspraul: (regarding my NOR recommendation for gta02) atmel are a bit of an odd shop. they have lots of very different things. not sure how they got there. either lots of mad scientists in R&D or lots of acquisitions.
<wpwrak>
wolfspraul: back then, the atmel was the only one i could find with known good availability. i had some more on my list (see the first mail), but FIC sourcing never responded to my requests to find out if the part could be sourced.
<DocScrutinizer>
wpwrak: surprises isn't exactly the term I'd use. If your antenna is a combined TX/RX then you'll have a hard time to cut the line up to insert an amp for TX and not break RX by doing so
<wpwrak>
DocScrutinizer: which is of course why i wouldn't do such a thing ;-)
<wpwrak>
DocScrutinizer: lemme finish my brunch, then i;ll paste a few links showing the hard and the easy way
<DocScrutinizer>
so find some chip that has separate pins for RX and TX antenna
<DocScrutinizer>
wpwrak: I think I know the hard and the easy ways, back from my time with CiticenBand and amateur radio
<DocScrutinizer>
even the "easy" ways are not exactly easy, as you more often than not get issues with unwanted feedback, esp with amps that have high gain
<DocScrutinizer>
you can use a RF suited "switch" to bypass RX RF around the TX power amp, and you need some way to control that switch
<DocScrutinizer>
I could even imagine nowadays you can find amp chips that have switch and input TX sensing integrated
<DocScrutinizer>
also some transceiver chips have a TX-mode signaling line that can get used to control the switch
<DocScrutinizer>
there are some external active booster antennae that implement such booster/switch/mode-sensor circuitry
<DocScrutinizer>
e.g for GSM iirc I've seen those
<DocScrutinizer>
for wimax too
<kristianpaul>
(booster) links please :)
<DocScrutinizer>
kristianpaul: sorry, I have to google for those links just like you
<kristianpaul>
ah :)
<kristianpaul>
i tought you had already implemnted it ,)
<DocScrutinizer>
anyway for CB that design been pretty common, always attributed to "compensate for cable loss, to get the full allowable 0.5/2W to the antenna"
<DocScrutinizer>
for WLAN/WiMAX and GSM the rationale is about the same
<wpwrak>
note the built-in baluns and, at least in the case of the sky65352, DC blocks
<wpwrak>
and yes, the AT86RF231 has TX/RX switch control and also antenna selection outputs
<DocScrutinizer>
well, all pretty much in line with what I said
<DocScrutinizer>
and you of course "cut the line to insert amp", just it's a smart amp that has the switching built in, to bypass the TX amp for RX signals
<wpwrak>
(ironically, SiGe have several quite similar chips with proper data sheets)
<wpwrak>
of course, not that skyworks have devoured sige, there's no telling what will happen with these chips. e.g., will they just be killed ? or will they complement skyworks' collection ?
<kristianpaul>
*g*
<wpwrak>
s/not/now/
<DocScrutinizer>
wtf, 27dBm TX
<wpwrak>
;-)
<DocScrutinizer>
I think 0.5W RF output should suffice for friggin zigbee
<wpwrak>
vee vil roast ze enemy :)
<wpwrak>
i think the RF6505 has similar power output
<wpwrak>
(from RFMD)
<DocScrutinizer>
nah, 18dBm
<DocScrutinizer>
iirc
<wpwrak>
that's the RF6555 :)
<DocScrutinizer>
aah
<DocScrutinizer>
well, anyway have fun with PCB layout for such a critter
<wpwrak>
a case for multilayer
<DocScrutinizer>
like standing with your microphone in front of the 4m high tower of PA speakers
<wpwrak>
it's half-duplex ;-)
<DocScrutinizer>
you better know your way around RF layout
<DocScrutinizer>
it's NOT relevant if that's halfduplex, the amp never is halfduplex, it's realtime
<wpwrak>
but yes, it would be nice if the amps had a little less gain
<wpwrak>
the AT86RF231 can output up to 3 dBm, so for 18 dB, 15 dB would be enough. don't need those extra 10 dB
<DocScrutinizer>
you will want to plce the transceiver plus PA chip into a nice tight can, and keep the antenna trace properly buried inside the layers and as short as possible. Also make sure you RF-block *all* other traces running into the can
<wpwrak>
i wonder how bad it really is. seems that the 50 mW boards don't always have a can. so maybe these are still "safe"
<wpwrak>
or even 100 mW
<DocScrutinizer>
you always can find a layout that doesn't need a can, if you try sufficient number of different layouts.
<wpwrak>
the SKY65352 seems to be without can. 100 mW. they have very detailed PCB instructions. i guess that's a good sign :)
<DocScrutinizer>
you may even find a layout that doesn't need a can no matter what changes you do to the environment setup (place device on a steel table, next to a power cable, on top of another WLAN device...)
<wpwrak>
just make the case big enough ;-)
<DocScrutinizer>
(very detailed PCB intr.) seems I've read sth like "each tiny change of those details needs a complete re-evaluation of the whole design" OWTTE
<wpwrak>
OWTTE ?
<DocScrutinizer>
tiny change is as little as replacing the input receptacle by a direct connection
<DocScrutinizer>
or words to the effect?
<wpwrak>
well, you need to "evaluate" the design in any case. there's no such thing as "open-loop" design.
<DocScrutinizer>
yup
<wpwrak>
even though ron seems to think it exists ;-)
<DocScrutinizer>
nevertheless you hope your evaluation will yield OK result
<wpwrak>
(exists) well, outside stories of a week of black fridays in EE ;-)
<wpwrak>
(ok) sure. else, the merry tweaking begins
<DocScrutinizer>
there's nothing as funny as an oscillating power-amp
<DocScrutinizer>
I had a CB (27MHz) booster boc 50W based on a single electron tube with some additional passive gear and a transformer, rectifier, HUGE elco for the power supply. On turning right the power dial I got a feedback obviously from the antenna contraption to the poorly shielded input cable from CB-transceiver. The power meter needle hit hard on the upper mechanical limit which was at 100W scale, and same moment my PC, my radio clock, my
<DocScrutinizer>
modem and a number of other electronics in the flat rebooted ot went crazy
<DocScrutinizer>
but usually you just wonder wtf your audio amp's power transistors get so hot, while you clearly calibrated the thing to only draw like 50mA quiescent current and there's no signal and not even a speaker connected to output
<DocScrutinizer>
then you might learn it pushes 20W out via the open end speaker cable, on 100kHz
<kristianpaul>
hi Artyom
<Artyom>
hi kristianpaul
<kristianpaul>
did qi-bot give you a message?
<kristianpaul>
in any case
<kristianpaul>
09:13 < kristianpaul> Artyom prn_code he, well, i think there is a typo somwhere
<kristianpaul>
09:14 < kristianpaul> and yes i have a general porpuse register to write and read, actually even a test write/read command too :)
<Artyom>
yes, I've seen it couple of minutes ago in irc-log ;)
<kristianpaul>
good :)
<Artyom>
So, your test write/read command works fine?
<kristianpaul>
yes it does
<kristianpaul>
actually i implemented the HW_ID register as well :)
<kristianpaul>
but decide to add that general porpuse reg just in case
<kristianpaul>
btw i undertood from you that you dont initilize the CODE_NCO register?
<Artyom>
And what do you mean by "typo somewhere"? (about prn_cod)
<kristianpaul>
because no needed for accumlators later?
<Artyom>
wait a second, I will check my code...
<kristianpaul>
(prn_cod) yes, more precicelly i noticed namuru datasheet compared with that osgps array share some values, but not all
<kristianpaul>
hum..
<Artyom>
no, both CODE_NCO and CARR_NCO must be initialized. Otherwise these NCOs will not generate desired frequency...
<Artyom>
(prn_code): yes, some look the same (but for different PRN#) and some are different.
<Artyom>
I think correct way is to use namuru prn_codes
<kristianpaul>
you compared with gps-sdr ?
<kristianpaul>
or akos code?
<Artyom>
I used Numuru version in my experiments with acquisition - and it worked fine
<kristianpaul>
workfed fine include code detection and tracking? :)
<kristianpaul>
ah, you mean you took rpn keys values from namuru code?
<Artyom>
no, only acquisition ;) (I compared results with results from Akos code). Tracking didn't work in my case.
<kristianpaul>
need to get away from those 33°C today and send 3°C to wpwrak
<Artyom>
prn_cod depends on how PRN_generators are realized. (ospgs take prn_cod from gp2021 datasheet. Other prn_cod for namuru means that they made generator in a different way. Difference can be for example in the shift_register direction or anything else).
<kristianpaul>
yes thats truth..
<kristianpaul>
well you know more that i on that topic, i even cared to understand it yet :)
<Artyom>
So, what is the current state of your work? Still fighting with accumulators? Can you give a link to the last version of the main.c?
<kristianpaul>
wich main.c?
<kristianpaul>
osgps?
<kristianpaul>
yeah, still fighting with accumulators.. :/
<kristianpaul>
i'm not using osgps yet with namuru, actually i jsut wrote some silly commands for the milkymist bios to take care about initialization and read STATUS and accumulators
<kristianpaul>
all comented in evry source code, i know i must move to somwhere else, after it works :)
<Artyom>
as I understand you try to call namuruinit-function? Is it correct?
<kristianpaul>
yes
<kristianpaul>
and later namururstatus
<kristianpaul>
polling for now
<kristianpaul>
Artyom: time_base.vhd line 87 why you compare against 4?
<kristianpaul>
just curious well i'm not using sample clk anyway...
<kristianpaul>
you tried to generated clock for you maxim frontend from namuru?
<Artyom>
Good question ;) I don't remember exactly. But at first I should note that I use 80 MHz clock. And I played a little with accum_sample_enable. May be this shift (4 against 6) seemed for some reasons better to me...
<Artyom>
I don't use sample_clk too.
<Artyom>
In my case I take 16MHz from numuru and multiply it by 5 in FPGA and use 16*5=80MHz as a clock source for namuru.
<Artyom>
I take 16 MHz from my front-end (mistake in the previous message)
<kristianpaul>
so in the fpga just a single clock?
<Artyom>
yes
<kristianpaul>
and this muñtiply dont affect the sign/mag sampling?
<Artyom>
and async access to mcu
<kristianpaul>
btw wich cpu are you thinking about for purse softwre processing?
<Artyom>
well, I didn't think about it ;) But you are right: there are potentially some possible problems.
<kristianpaul>
i asked peter mumford and he said, that, "clocks. The main thing with clocks is to ensure that the correlator clock is synchronised with the front-end clock"
<Artyom>
As I understand DSP: if I multiply sampling freq by 5 then I should get 5 copies of the spectrum. But I don't think that it's a problem
<kristianpaul>
so i prefer deal with cross clock domains between namutu and milkymist that try to beat namuru with two clocks doamins
<kristianpaul>
and is 16Mhz too low for you MCU async memory interface?
<kristianpaul>
cause namuru with is avalon implementation is almost ready for that, well i think it lacks an ACK signal but thats all
<Artyom>
clock domains - this is what I don't know for now...
<Artyom>
actually mcu-fpga interface is my weak place for now :(
<kristianpaul>
but you have a non-soft way to test all is okay?
<kristianpaul>
like in the fancy way a gps simulator?
<kristianpaul>
or may be something more cheap and simple like a another board that mimic maxim behavior with a pattern
<kristianpaul>
but i guess if you can read and write all is okay :)
<Artyom>
I think I would try to use two possible alternatieves:
<Artyom>
1. Like it is done in gp2021. One namuru channel can be used as signal generator
<Artyom>
2. I have access to simple gps-simulator. May be I will try to use it too. But I don't like this device :(
<kristianpaul>
oh, wait you mean i can generate fake gps signals with namuru?? (even with no 10.23 atomic clock ;))
<Artyom>
yes, there is no problem to use one namuru channel as signal generator... I don't see any problems
<kristianpaul>
he, well i never tought about it..
<Artyom>
I read about it in gp2021 datasheet...
<wpwrak>
DocScrutinizer: (amp fun) ;-)))
<kristianpaul>
Artyom_: so, your current namuru software work flow is: init NCO -> set PRN LEY -> SET both prog TIC and ACCUM TIC - > SET EPOCH
<kristianpaul>
then keep polling status and read accumulators just after?
<kristianpaul>
graph it somwhere and find a peak :)
<kristianpaul>
i remenber from gp2021 datasheet it suguest some loop like that
<kristianpaul>
i just dint think yet about how to stimate a threshold..
<Artyom>
Last version is left on my work. My old version has the following flow: TIC periode -> accum periode -> cho_prn_key -> ch0_carr_nco -> ch0_code_nco. Then polling mcu-pin. Then reading 1. status 2. new_data. If new_data[1]='1' then output accumulators
<Artyom>
it's not difficult to chose threshold. You can record correlators output (better to recors sqrt(i^2 + q^2) for early, prompt and late)
<Artyom>
usually there is a high peak when carr_nco and code slew are close to what satellite is transmitting
<Artyom>
Just remember this value and compare it to the case when carr_nco or code_slew are far from what satellite is transmitting
<Artyom>
And choose a threshold near the peak value (a little smaller)
<Artyom>
Of course you can calculate this value more strictly
<Artyom>
You can use Neiman-Pirson law, for example. But it will demand some time to learn theory...
<Artyom>
it;s time for me to leave. gn ;)
<kristianpaul>
n8
<rjeffries>
wpwrak maybe you can pitch Ben Nanonote as a VGA tester?