Problem with custom SYSEX_RESPONSE values

[jguille2]

Hi! I have a question... and I think a bug to fix.

Which custom indexes can be assigned to SYSEX_RESPONSE array?

I used the range 0xC0-OxCF, and it runs ok until version 10.0 (version 9.3 is ok)

The problem is in this line ( if (currByte > 0x7F) { ). If the real range is greater than 0x7F, we must change this condition.

Thanks for your work!! I'm enjoying firmata.js with Snap4Arduino.

Joan

[soundanalogous]

All sent using SYSEX must be 7-bit (the MSB must always be 0). If you need to send a larger value, you need to pack that value into multiple 7-bit bytes.

[jguille2]

Ooppss! I'll have to change many things (for backward compatibility) :((

And I'll do it (of course), but I ask you one thing: To stablish a range for custom SYSEX_RESPONSEs.

Current indexes used in firmata.js are 0x79, 0x6C, 0x6E, 0x6A, 0x77, 0x73, 0x42, 0x45, 0x43, 0x71, 0x75, 0x72, 0x60. But you can implement new responses. We need to have clear which indexes are available to use in firmata.js projects.

Thanks for all!

Joan

[soundanalogous]

If you're talking about custom as in only for your applications, then use anything in the range 0x01 - 0x0F. If you are talking about a custom response that may have a use case beyond your personal app, then look into using the extended ID range as described in this document: https://github.com/firmata/protocol/blob/master/feature-registry.md

[jguille2]

Thanks Jeff!

I close this issue... but only a final question: If I implement in a custom firmata more than 15 responses, can I use the 0x10-0x1F (or other) ?

As you said, I can merge responses (using the first data byte to distinguish them)... but I wonder if it's mandatory. To show the context, we are using this ExtendedFirmata

Again, thank you so much for your work!

Joan

[soundanalogous]

Ideally you should use a single command byte for the each feature and a subcommand for each response.

Also, the Wi Nunchuck sensors can be accessed via Firmata I2C. Both Breakout.js and johnny-five implement that functionality.

Since you have a pulseIn feature, you may be able to use that with a combination of a digital pin message to read the ping sensor from the client side.

[jguille2]

Thanks for your time!

You are right I have to check the code. I made it just learning... but many people is using it. I have to think the strategy to make the changes (not to break suddenly all the projects).

No problem. I can continue with 9.3 (or hacking current version) for a while.

Thanks!!!

Joan