Log from #neuros IRC channel

Bruno, would you like to tackle this one?

<Bruno>

squarrootticus: You're it!

<Bruno>

Joe, I think taht there is a lot of wishful thinking here.

wishful is my middle name :)

I'm just a troll. I admit it. Troll troll troll. :)

<Bruno>

Video and JTAG are very different in nature -- cannot share a bus

<Bruno>

At least not easily.

<Bruno>

Universal busses tend to not be universal at all.

<Bruno>

The most universal bus that exists is USB.

<Bruno>

It is in its 2rd public version,

<Bruno>

Oops -- 3rd

<Bruno>

(1.0, 1.1, 2.0)

<Bruno>

not to mention the OTG spec

<Bruno>

and it does NOT support everything.

<nates>

My old Archos had a line-out I believe some modified for debugging, a USB connector, an expansion port for the camera, DVR add-on, etc, and video-out port. I think we'll need multiple connectors to do all that.

<Bruno>

Nates: You have spoken well.

you could put some logic in the connectors to support different hardware/busses

<Bruno>

Aside from the cost,

<Bruno>

making things universal require an exponential amount of engineering

<Bruno>

with each type of device supported.

<Bruno>

USB, as an example, is still full of bnugs,

<Bruno>

and it has billions of dollars invested in engineering.

<Bruno>

And it does NOT support everything.

<Bruno>

That said ----

<Bruno>

We could possibly define all the functions we would need,

<Bruno>

then design multiple interfaces with functionalities grouped

<Bruno>

as required.

<Bruno>

I am sure that JTAG and audio will NOT share the same bus,

<Bruno>

but possibly video input and output could share one.

<Bruno>

The key to these thing is to define the functionality UP FRONT

<Bruno>

wich requires a lot of planning and a commitment to not change the mind.

<nates>

The Archos required an expansion device for video in.

<Bruno>

Both are dangerous things.

well, I didn't literally mean JTAG, but I was thinking of the daughterboard which provides ethernet and serial and you suggested that it needs 40 wires or something

<Bruno>

I am a firm believer on dedicated connections...

I was wondering if those 40 wires could form a bus for example, that's what I was getting at.

<Bruno>

Well, if you want Ethernet, let's have Ethernet...

<Bruno>

I think that we should have USB OTG 2.0,

<Bruno>

it is the closest thing we can have to a Universal Bus.

USB OTG 2.0, does that support high speed?

<Bruno>

Besides, hjaving USB OTG will allow the expansion of types (underline)

I thought all the OTG chipsets were 11mbits?

<Bruno>

Today they are, but the 480 Mbps chips are coming about

<Bruno>

It is important (assuming that we adopt USB, which is my recommendation)

bruno: "expansion of types" ?

<Bruno>

that we do not get hung of the available speed of the hardware,

<Bruno>

but start preparing the SW for the functionality desired.

<Bruno>

Once the HW evolves, so do the SW

[17:36]

<Bruno>

So, a summary:

[17:36]

<Bruno>

Connectors available on a audio machine of a given footprint:

[17:36]

<Bruno>

Audio line/mic in, line out

[17:37]

<Bruno>

S/PDIF out

[17:37]

<Bruno>

USB OTG

[17:37]

<Bruno>

From the cradle (if portable)

<Bruno>

Ethernet (native), serial port

<Bruno>

If the device is not portable, it could have a VGA out or TV out

<Bruno>

==== For a video device:

so that implies you do real time debugging using the cradle through USB?

sorry go ahead.

<Bruno>

Add NTSC/PAL composite and S-Video input

<Bruno>

Add NTSC/PAL composite and S-Video out.

<Bruno>

Maybe SCART or component out if high end device

[17:40]

<Bruno>

A 1394 interface could be a nice thing to pair it to some STBs

[17:40]

<Bruno>

The development/expansion cradle/chassis could have BT656 I/O

[17:40]

<Bruno>

=====

[17:41]

are we still talking about the neuros?

[17:41]

<Bruno>

I do imply that you can debug using EThernet and serial via cradle.

[17:41]

<Bruno>

We are talking about A nNeuros

how does the cradle connect to the device?

not through USB?

<Bruno>

It depends on the device's footprint.

<Bruno>

It could be as solid as the current multi-pin scheme of NII, or

<Bruno>

it could be as simple as the 4-wire connections on the PALM-I handhelds

<Bruno>

USB is always a good choice to connect "mundane" peripherals.

<Bruno>

The only drawback of USB is that the driver is never available for the platforms that we want it on.

well, the device will have a one piece design so, we can afford to have a significant connector at the bottom if needed

[17:44]

so would a USB OTG allow the connection of a webcam for example?

[17:44]

<Bruno>

Yes.

<Bruno>

As long as the USB is 480 Mbps. Not today with DMxxx, but soon.

when will those chipsets be available?

<Bruno>

Today if you want 480 Mbps you use an external chip, and lose the OTG capabilities.

Bruno: these soon-to-come high speed chips will be expensive, because they will be new to the market. or not ?

<Bruno>

It is not a "bad" thing, it just can't be flipped around.

<Bruno>

No, they will be pretty cheap.

good

<Bruno>

There are non-OTG (target only, in their majorty) devices that cost as little as $2.

so Bruno what about those external controls, like the DJ type stuff for pitch control, etc.

<Bruno>

Of course, they require lots of driver development.

can they also connect (HW wise) using OTG?

<Bruno>

These are incredibly low data rate.

<Bruno>

Anything will work for these. Even the 12 Mbps current USB ports will look like a super-highway for them.

<Bruno>

Just as a comparison,

what about RF or bluetooth rather than usb

<Bruno>

MIDI is used to control many music instruments at once, and the data rate is 31 Kbps (K, not M)

something wireless

and putting out a remote before you put out an external dj control doohicky :)

solomonn: isn't that more power expensive ?

<Bruno>

Bluetooth is good for control and low/medium quality audio.

could be

solomon: no definately, I agree.

<Bruno>

Bluetooth these days is pretty affordable.

idunno though, with usb you have to power the device that's plugged in

[17:50]

<Bruno>

ALL devices must be powered SOMEHOW, USB just makes that connection explicit and visible.

[17:50]

but bluetooth would still be a lot more expensive than IR or 37MHz or something like that for a remote, right?

Bruno: i was talking about power consumption, not price

IR wouldn't be a good move

<Bruno>

Joe, yes.

you can't stick the neuros in a backpack and control it from outside the backpack using IR :)

<Bruno>

nero: all devices consume power, and the USB interface block is no exception.

bluetooth seems like an awckward position between price and bandwidth

<Bruno>

Power is a relative measure:

<Bruno>

If you can provide it, any consumption is good.

solomonn: I agree with that as well, the remote should be RF

Bruno: of course, but comparing USB and BT, what consumes more ?

<Bruno>

The OVERHEAD drain of the USB block per se is not bad.

for a portable device.

RF would be sufficient for what you're talking about, but then bluetooth would be more scalable

<Bruno>

BT by far.

you could make the neuros work with other devices that other people will make 5 years from now

and probably some that are already around

<Bruno>

BT had the advantage of being able to send audio to your headset, and talking to your cell phone, if this is what you are looking for.

the life of the device probably won't be that long

kind of overkill

true

<Bruno>

On the other hand, 802.11 could talk natively with your computer.

personally iw ould rather it was RF

for my purposes it would consume the least power and do what i want :)

Bruno: yeah, then you could sync without going and getting your neuros out of your room

that would be kinda sweet

BT's bandwidth and latency are not good for audio transmission, especially in "noisy" environs. Maybe a new, higher-width BT would be

[17:55]

solomonn: what kind of things are you imagining connecting with BT?

[17:55]

Somehow my connection dropped. I am back.

[17:55]

JoeBorn: i can't imagine anything really. just that when something comes out that you never thought of, it would be a matter of a firmware change to make it operate

bruno: I assume that debugging through USB is not too ideal, I mean you have to bring up USB first right?

Correct.

Why is this thing saying Bruno99 now???

by request, a repeat since Bruno was offline:

BT's bandwidth and latency are not good for audio transmission, especially in "noisy" environs. Maybe a new, higher-width BT would be

what about 802.11's power consumption?

You are very right about BT bandwidth and latency.

BT 2.0 is better but not great.

802.11 sucks (lots) more power than BT, but works (lots) better.

hehe

Any and all wireless connections will have

their coverage limits.

Once you go outside that, or get in the range of

802.11 would be nice but RF still seems more practical

I wouldn't even trust 802.11 for realtime data, like audio. You need something like CDMA that has basically zero latency but cuts out when the noise floor gets too high

interferers, then they just degrade and ultimately fail.

<nates>

So why would we want any wireless technology? Just future expandibility?

<nates>

Remote?

I would limit any wireless to control and communication, and forget about wireless audio altogether.

nates: that's the most immediately desirable application :)

Just my $0.02

I think wireless would we useful for swapping files on the go.

CDMA has its problems, but because it is not used a lot in data, people think better of it. It also has its ugly side.

squarooticus: yeah, i agree

JoeBorn: with other neuros users you mean?

CDMA has a different set of problems that make it more applicable for realtime applications

And it is NOT zero latency, as you have to run and sync the correlators.

well, if it's WiFi then other devices generally.

that would be nice, but then I wouldn't mind plugging 2 neuros's in with a usb patch cable

Okay, zero isn't right. Predictable is a better word

WiFi can (and is) used to pass audio.

So is BT abd CDMA.

I agree that audio should NOT go via radio.

Unless you have to, that is.

what kind of transmission bw do BT and RF have?

And even so, in a somewhat controlled environment.

i imagine RF would be crummy for any file swapping but i don't know

RF is very good for control. We should

<nates>

Why would you want to transfer audio wirelessly with a portable? I'm not seeing why...

make sure to keep this in mind.

nates: for the same reason that your cell phones have BT: convenience.

of course the fm transmission feature covers that a bit

People swap files every day with RF. 802.11 is actually pretty good at it, in spite of being RF.

Bruno99: but we're talking much lower power RF than 802.11, right?

ok, Bruno, so just let me clarify, above you suggested I/O being for audio and mic in and out and OTG

My recommendation is to have RF for human interaction only.

then cradle having ethernet and serial, so how does that cradle connect to the device?

Bruno99: could the cheapo RF built in to acccomodate a remote, also be used to send files from one neuros to another, and not all that slowly? :)

JoeBorn: don't forget s/pdif, i like that bit :)

Ok, I will answer the 2 questions.

(on the device)

The easy answer to solomon: you get what you pay for. Cheap, fast, reliable. Pick 2.

I agree, I like s/pdif too (I was just saying audio for shorthand)

Yeah, my iRiver IHP-120 has s/pdif optical out. Pretty sweet to be able to hook it up to a DD receiver and get clean audio

Joe: The cradle in my view could hous the peripherals that a portable unit would not

possess, or enable "bigger" systems.

A good exaple is access to JTAG.

Bruno: I think that makes good sense, but I'm just wondering what the connection to the cradle will look like since I'm sure we need to give that good consideration

If you are building code, you don't need the unit to be portable.

that's for sure

The physical connection would need to be a multi-pin header or similar.

The connection between NII and backpack is an example.

perhaps this cradle could also house a bigarse battery

That particular connector has

everything that you need even to add

then it could either be used to give the neuros a much longer battery life, or to give it an acceptable battery life while using these "bigger" features

Ethernet, BT or 802.11 to the N-II.

well not really since mic in would not possible on the backpack, right?

although i suppose if i were to choose, i would just get a battery pack that connected the same way but didn't have all the big features

Bruno99: would a small pin-connector like the one found at the bottom of most cellphones work in this case ?

It is just not efficient for it. Obvioulsy it was not a design consideration at the time, but the expansion capabilities are there

No, these connectors don't have enough pins.

But one interesting point to notice

is that SATA drives are a reality, and you can hook these up with pretty small connectors.

They are just power hungry, but they can be perfect for a stationary cradle.

3.5" hard drives?

Is the proposal for microdrives or standard laptop drives?

And they are fast enough for video, high end audio (even multi channel)

seems like you would want to allow for a cradle to be stationary or remain portable

and probably just make one offering instead of 2

The reason I ask is that one of the selling points I've used to convince people to buy the Neuros is that it takes standard laptop drives

something that will operate portably but of course you can plug it in if you want and use it more than 8 hours or whatever

if you decide to go with a large connector like the one in the current N2, please make it connectable/disconnectable with less force, and also have it better protected (sliding cover, or similar)

nero:

The mechanicals of the current connector are (in my opinion) far from great. But they work.

squarooticus: last i heard it was for 2.5" laptop drives, smaller than standard but also smaller, which is nice :)

If we need a big connector, it will need pretty good

[18:12]

force to latch on. They all do. The ones that don't

[18:12]

have exorbitant cost (>$40) or limited life (<10 insertions)

[18:12]

Pick yor poison.

[18:13]

the problem with the connector isn't really the force involved, but the limited leverage

[18:13]

I think thatthe current connector could have longer fingers, so there would be

[18:13]

what about the connectors at the bottom of PDAs? they have a ton of pins

less relaince on the perfect alignment for insertion.

Joe, these are the ones I think we should use.

At least that is my first though.

But all these issues we talked about are still there.

Bruno: I see, and that pin configuration would be something proprietary that we make up?

Only somebody else has mulled them over for us.

<nates>

The Archos's connector, which I found very easy and supported USB2 speeds www.ixbt.com

What do you mean by "pin configuration"?

or could it be something standard like PCMCIA?

well, like the current connection between the backpack and the player in the current neuros

is just some random collection of wires from what I can tell.

nates, that has just a few pins and is way too bulky

I've never conceived of anything that it could support

It is not just a random collection of wires. Someone (Tim?) probably spent a few hours thinking about it.

I'm partially being funny, but my point is two things, one it's hard to have adequate "design considerations" up front and two it's very nonstandard and arbitrary

PCMCIA is a standar bus that we could leverage.

We could use the form factor and the connectors, which

lots of people have spent lots of time engineering.

that's why I'm drawn to something standard like PCMCIA, or better yet, PCI which is obviously something that