get sensor by port

[Saeid Nourian]

it appears that the port number of request object is not considered at
all when choosing a sensor configuration

so in this method:

AbstractSensorDevice.compareSensorConfigAndRequest(SensorConfig
config, SensorRequest request)


I added this:

if (config.getPort() != request.getPort())
return 0;


I will update svn unless you see something wrong with this.

Or is there an easier way of getting sensor by port number?

[Scott Cytacki]

Doing that will unfortunately break the existing usage of the code.  In almost all cases the port in the request is just set to 0.  It is ignored so it doesn't mater where a student plugs in a sensor, as long as that type of sensor can be found somewhere then it works.

I realize this has obvious pitfalls especially if you are planning to use lots of temperature sensors at once.  You'll want to know which one is which. 

A further complication is the reporting of ports in a SensorConfig.  Each sensor manufacturer has a different concept of 'ports'.  The pasco devices have modules that plug into an interface.  And each module can have up to 16 sensors.   So in that case is the 'port' the place where the module plugs in, or is it some how the index of the sensors.  

Other devices have internal and external sensors, so then if the port 'numbers' start with the internal sensors.  The external ports might not match the labels on the device. 

Can you come up with an abstraction/api that can handle all of these cases?  I should be available to bounce ideas off of.   You might start by describing your use case where you need to specify the port in the request, and then we can think about how that might work with all the various devices. 

Scott

--
You received this message because you are subscribed to the Google
Groups "org-concord-sensor" group.
To post to this group, send email to org-conco...@googlegroups.com
To unsubscribe from this group, send email to
org-concord-sen...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/org-concord-sensor?hl=en?hl=en
Google Code project for org-concord-sensor: http://code.google.com/p/org-concord-sensor/

[Saeid Nourian]

The use case is basically the ability inserting netlogo sensor
components in a netlogo project.
As its only parameter the sensor components receives the port # to
identify which sensor should represent this netlogo component.
The netlogo component would then continuously display the sensor value
returned by the sensor identified by port #.

Now the goal is to allow user to identify whichever sensor he/she
wants. I thought port # is the way to go, but if as you say there are
some sensors that use different values for external and internal ports
that could be problematic. Also we need a way to identify sensors that
are attached to different USB inputs of a same computer.

That said, for now I can find a way around this by just hard coding it
for the specific need of augmented reality project which uses a single
type of sensor. But we may want to come up with a better more generic
way of doing this for future projects.

[Scott Cytacki]

On Thu, Feb 23, 2012 at 11:13 AM, Saeid Nourian <snou...@concord.org> wrote:

The use case is basically the ability inserting netlogo sensor
components in a netlogo project.
As its only parameter the sensor components receives the port # to
identify which sensor should represent this netlogo component.
The netlogo component would then continuously display the sensor value
returned by the sensor identified by port #.

Can you explain more why the interface to netlogo component is a port #?  Is that based on an existing Netlogo API or is there flexibility there?

 

Now the goal is to allow user to identify whichever sensor he/she
wants. I thought port # is the way to go, but if as you say there are
some sensors that use different values for external and internal ports
that could be problematic. Also we need a way to identify sensors that
are attached to different USB inputs of a same computer.

Do you know if these netlogo models are intended to be created by students, or are the models created by authors and the students use them?  If it is the latter, and the model is intended to support different types of sensor interfaces, then I think there will need to be some UI for the user to pick which sensor should be 'attached' to each of the netlogo components.   

There are a lot of ifs there though.  Perhaps the initial goal is only to work with one sensor interface.  In that case it would be useful to specify ports specific to that interface.  In that case it might be best to use a port name instead of a number. Then each sensor interface can define its own format for these strings.  So pasco could be "module_slot:1,sensor:1".  Labquest could be "external,sensor:1".  It seems to me it would be useful for the sensor library to support both modes of use: 

- generic 'port' specification that works with any supported sensor interface

- 'port' specification that is for a single type of interface

 

That said, for now I can find a way around this by just hard coding it
for the specific need of augmented reality project which uses a single
type of sensor.

That sounds like a good way to go, so we don't have to rush to make the change.

 

But we may want to come up with a better more generic
way of doing this for future projects.

Definitely.

 

Scott

[Stephen Bannasch]

FYI:

A note I posted to the visual-leaders email list:

A note: while this works when running NetLogo as an application NetLogo extensions (with native libraries) do NOT work withNetLogo applets.

At 10:39 AM -0500 2/23/12, Robert Tinker wrote:
>Hi:
>Is the implication that this would not work in WISE4 because it
>requires applets?

Yes.

The NetLogo 5.0 manual page on applets states:

http://ccl.northwestern.edu/netlogo/docs/applet.html

Many extensions can be used in applets. Simply place the folder containing
the extension jar in the same folder as the model.

Extensions that require native libraries don't work from applets. This includes
the QTJ and GoGo extensions.

It is possible this could be fixed but my experience in getting the sensor applet working an all browsers with native librariesis that this can be quite tricky.

>What are other implications?

In the short/medium term getting a variation of the NetLogo applet working that easily supports data communication both in and out to JavaScript would also allow us to connect output from the existing sensor applet to the NetLogo applet.

Also in the short-medium term converting selected NetLogo models to html5 and using these directly with the sensor applet wouldwork.

In the medium/longer term using new JavaScript-based modeling environments (NetLogo in JavaScript??) would work much betterand also be able to work on tablet and smartphone browsers.

However until the google grant gets sensors working in browsers on iOS and Android systems we won't be able to disseminate evenHTML5 models using sensors on tablet and smartphone browsers.

[Saeid Nourian]

> Can you explain more why the interface to netlogo component is a port #?
>  Is that based on an existing Netlogo API or is there flexibility there?

no it's not part of existing netlogo api, i just decided to send an
int called port to my netlogo extension. I could just as easily change
its type to a string and rename it to something else.