In many examples for the sensor multiplexer, I see code lines called HTSMUXinit(); and HTSMUXScanPorts(); When I type that in with Xander's drivers included, it is not recognized. I also find trouble making my sensors work through the sensor multiplexer. I don't know if these lines are important for this. I did do definitions of what ports the sensors are in and naming them. I have robotc 3.55.2 and I have the latest of Xander's drivers.

Actually not in ur examples but in ones i see online, there is that line that says it initializes the sensor mux. Basically, I am having difficulty making the sensors work when they are connected to the sensor mux. Just clarifying, is all u have to do is declare what port the sensor is in, or do u have to do more. Is there like a way of specifying what kind of sensor it is that i need to do? I know one exception is the light sensor where you have to write LSSetActive if im not mistaken. The sensors I have on the mux are 2 light sensors, a color sensor, and an ir sensor. I just want to have a clear understanding of how to make each of these work when connected to a mux because they dont respond when i just declare them. One thing I've been trying to do with the color sensor is make it emit a certain color when my force sensor(not on mux and works) is sensing a certain value. I mentioned it as a constant and said the port, and then I just proceeded to saying like if(SensorValue[FSensor]>45) then SensorType[HTCOLOR] = sensorCOLORBLUE; This doesnt work for me unless i plug it in directly to the nxt. Is there something else i need to do. I cudnt find an example for emitting color only sensing it.

Thu Jan 03, 2013 12:24 am

inandi2015

Rookie

Joined: Tue Jul 17, 2012 8:11 pmPosts: 20

Re: Sensor Multiplexer Initialize

Also is it better to do a define statement for the the ports that sensor in or a constant or does it not matter.

The LEGO Colour Sensor does not work with the HT Sensor MUX. That sensor is neither properly analogue, like the sound and light sensors, but a weird, semi-digital (but not I2C) / super fast analogue sensor that uses a different channel on the main processor of the NXT and not the co-processor.Any examples for my drivers that do NOT come with the latest version of Driver Suite are not supported by me, so if they don't work, you can either assume they're obsolete or you have to ask their author for info.The SMUX scan function has been removed from my driver suite for ages, so the examples you are looking at are seriously ancient. I don't even remember when you last had to use that function, it was probably in version 2.x; I'm now on version 3.x.

ok so i switched my color sensor with my force sensor and put the force sensor into the sensor mux since it is supported since i can see an example of it, however the only value that returns out of the force sensor is 1021 which is an odd # that im not sure where it is coming from. i used ur example structure. any ideas?

Can you tell me what you did to make it work? Was it a battery issue? Also, what do you mean by normalised value? Are you referring to the 0-100 value you get from a light sensor? That would reduce its resolution dramatically. Could you tell me what the use case for this would be?

im pretty sure it was a battery issue, altho im not completely sure, it cud have also been that the mux was off at some of our testing times, so thats the value pof 1021 it jumps to with it off. when i mean normalized, i mean like the values that u get for the for sensor without a mux when u just use the regular sample code online on http://www.usfirst.org/sites/default/fi ... rTests.pdfgo down to the chart and look at the robotc section. the values that they receive from trials are the raw values. the normalized values are those values divided by 10 and you use it in robotc like if(SensorValue(forcesensor) <45))for the raw values u would say if{SensorRaw(forcesensor)<450))judging from the values we get from debugging, they are raw values that look like the values in the hundreds like the chart. we want to use normalized values since we already tested them working on the nxt with the regular code, but we want to use the same values, just switching the force sensor to the mux and using ur code. if its not possible, we can always test with raw values and write a program with that. we cant just directly multiply 10 since the values dont fully follow that rule with ur drivers/code

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum