Making custom sensors: What would be the demand?

[mattallen37]

Extra NXT bricks networked with RS485. 14 NXTs would provide 42 sensor ports, assuming port 4 was used for RS485. There would also be 42 encoder enabled motor ports.

Other options exist as well. There are several different motor multiplexers that support encoders, as well as several sensor multiplexers.

[HaWe]

no, matt, please keep to the topic.

Not 40 sensors to 14 bricks but 40 sensors to ONE brick was my question.
PLUS 15 NXT encoder motors.

[mattallen37]

NXTs connected as RS485 slaves can be programmed as simple multiplexers.

So you're looking for someone to make a very very large sensor and motor mux? With the extremely low demand for such a device, it would probably cost a fortune.

[HaWe]

My question was not about a rs485 network. I never saw a well-working rs485 network of 42 NXTs where you can read and command all sensors of all kinds and motors exactly as if they were attached altogether at 1 single NXT.
Did you?
(ok, I admit that you started beginning with a very promising appoach for this - but having to buy 42 NXTs and program and control them just as they all act together like 1 single one?? And 42 NXTs also would probaply cost a fortune, don't you think? - )

But anyway, my question was about all I/Os at only ONE NXT.

As we have 3 motor ports and need 15, so 12 are missing:
1 sensor port for a 12x NXT encoder motor multiplexer.

3 sensor ports are left for 40 required sensors:
to each remaining sensor port ONE 16x universal sensor multiplexer (for all kinds of sensors, either Lego or 3rd party or homebrewed, maybe 8-10 for i2c types (high speed read/write ), and another 6-8 for analog types).

OK, that would admittedly be a challenge - but really nice to have....

[mattallen37]

I was saying 14 NXTs for 42 sensors, not 42 NXTs. Due to impedance, the RS485 transceivers are rated for up to 32 devices on a bus.

Based on the tests I did with multiple NXTs using the RS485 multiplexer programs, everything seemed to work perfectly! I even added support for user data as you requested.

Whenever a system supports 3rd party/homebrewed sesnors/interfaces, it needs drivers specifically for that device. It is utterly impossible to support every sensor. If you want a do-all mux, then you would have to be able to re-program it based on the sensor specifics, so for your sake, I suggest staying with NXT.

Why do you need high speed I2C? The NXT doesn't even support it.

[HaWe]

yes you're right, I read that wrong, it was about 14 NXT (still quite a lot, but ok...)
I'm having trouble with several NXTs in networks and to understand the appropriate protocols and properly managements because those NXTs are not as simple scalable as I thought they would be.

no highspeed i2c? Ithought I read that there should be support for this recently...?

When I once bought my first NXT I was thinking: "wow! 4 ports which could be configured as i2c! that's over all 4x126 = more than 500 sensors to attach...."
It took quite a long time for me to recognize that I understood this feature completely wrong. But at least 40 sensors at 1 NXT would be fine anyway.

[mattallen37]

Well, it may be called high speed, but it's no where near the high speed "standard". High speed is usually considered to be 400k bps, and low speed is usually 100k bps. The standard NXT FW uses 9600 bps, but John made some changes to support faster speeds, although still not even the low speed "standard".

[HaWe]

surprising...

[HaWe]

indeed, the I2C implementation for the Fischertechnik TX controller also supports both 100 and 400 kbps.

[mightor]

The difference is that the FT controller probably uses hardware I2C and the NXT uses a bit-banged approach for the sensor ports. The hardware I2C on the ARM7 chip in the NXT is used to communicate with the ATmega. It was a design trade-off, I guess.

- Xander