These are chat archives for Makeblock-official/mbot_nodebots

29th
Sep 2016
ajfisher
@ajfisher
Sep 29 2016 02:35

@noitsme things you can try and some clarifications:

  • can you build a small JS app and have it actually connect to the HID (ie are you seeing the device properly?)
  • Re firmware in this case you can use the same firmware as the bluetooth one, The Wireless module for the mbot used 115200 baud rate which is the same as the BT module. As such use the same --firmata=bluetooth and you should be good.

Just to clarify are you using the 2.4GHz wireless module or the WiFi module as they are two different things? The latter is an actually WiFI endpoint that connects to your network, the former has a USB dongle you plug into your computer which talks to it like a wireless keyboard or mouse (that's not using BT obv).

noitsme
@noitsme
Sep 29 2016 03:44
I have the 2.4GHz wireless module (the one which needs a dongle that ships with mBot)
and I have pretty much all your JS sample apps working against my mbot configuration when connected over USB. and over Wifi, I can see the HID details, i can print out the device path, the other metadata.. and it matches what shows up in the hardware device manager settings as well.
Also, i did basic sanity tests like if the 2.4Ghz wireless module plugged in or if the mbot is turned off, then the program immediately terminates with appropriate message
** if the 2.4Ghz wireless module IS NOT plugged in or.
noitsme
@noitsme
Sep 29 2016 03:49
In this code file, line 28 is where the program never reaches. https://github.com/Makeblock-official/mbot_nodebots/blob/master/examples/wifi_motors.js
one more clarification that would help: in the above sample file, on line 26 is it supposed to be io.once('ready', function(){
} or should it be io.on('ready', fn) instead? I did try both versions but it didnt seem to help
noitsme
@noitsme
Sep 29 2016 03:58
One thing I noticed.. on windows 10, the HID path for the 2.4GHz wireless module was a really long complicated path and not simple like /dev/tty.Makeblock-ELETSPP that you got in linux/mac. Another thing you mentioned in the repo for troubleshooting was to use screen program; i couldnt find an equivalent program in windows that worked for my purpose.
am planning to redo the setup and test from a raspberry pi machine connected to mbot.
hopefully that way I get the shorter device path AND use screen utility to see if am able to talk to mbot over wireless
One more thing that was puzzling me.. in your BT (Bluetooth) section in the readme, you mention to remove the BT chip - then install firmata for bluetooth - then reinsert back the BT chip.
I didnt do that step for the 2.4GHz wireless module chip. Could that be a problem?
ie. physically remove the chip first before running interchange?
noitsme
@noitsme
Sep 29 2016 04:04
BTW I did see you gave some suggestions in the past here: jsconfcn/nodebots-session#6
but I am unsure if those apply just to bluetooth, or wireless as well?
ajfisher
@ajfisher
Sep 29 2016 04:52
Okay - I think I know what this might be
Actually scratch that - the example copes with this. What I was thinking if that it might not be getting the right path for the device and passing it to the io plugin. Having said that, if it's not device[0] then it's not going to work

Something worth testing is print out the length of the device list that comes back here:

var allDevices = HID.devices(0x416,0xffff);
console.log(allDevices);
var hiddev = new HID.HID(allDevices[0].path)

And make sure you're only getting one and it's the correct one.

Other than that, it's not getting the ready response back. If you can try and connect to it using a serial terminal (putty, hyperterm etc) and connect to that device then when you reset the mbot you should see the firmware name print out per the note I made about connecting over screen. If that doesn't work then it's a good indicator that the firmware isn't talking to the wireless module
And yes, you absolutely 100% must remove the module before flashing the firmware or it won't write
noitsme
@noitsme
Sep 29 2016 05:11
Awesome! thanks for the help @ajfisher.
I havent / wont be able to test out those pointers tonight, but at least I got a direction now
And make sure you're only getting one and it's the correct one.
yes, I was getting just one back and the correct one BTW
i am gonna remove the module and flash it tomorrow. but just a node that with Screen, I had a hard time getting hyperterminal, putty etc doing similar test like you did using screen on unix and..
and now on linux (raspberry pi) I was having a hard time running screen because I couldnt identify the tty matching the mbot yet.
rough night. will pick this back up tomorrow. thanks a bunch!!
noitsme
@noitsme
Sep 29 2016 05:17
Scratch that! I just connected from screen to /dev/ttyUSB0 and it played the mbot startup sound. So thats the USB one. and not the UART one i was looking for. Hmm..
My lsusb lists my device fine.. its listed on Bus 001 Device 009. How do I map that to something on /dev/tty device? :) feel like a noob here
noitsme
@noitsme
Sep 29 2016 05:40
Quick update: just finished flashing the bluetooth firmware after removing the module
noitsme
@noitsme
Sep 29 2016 05:54
duh. I should have just used node hid package to print out the device path. Not sure why that didnt occur to me. : )
noitsme
@noitsme
Sep 29 2016 06:07
cant get node-hid to install despite repeated attempts; back to trying on windows where i already have it setup
noitsme
@noitsme
Sep 29 2016 06:18
Ran the wifi-motors.js program, and same result. code never enters the ready loop. Here's the HID it prints out on windows.
{ vendorId: 1046,
productId: 65535,
path: '\\?\hid#vid_0416&pid_ffff#7&2b595659&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}',
manufacturer: 'MemsArt ',
product: 'RF UART',
release: 272,
interface: -1 } ]
calling it a day. hopefully tomorrow i can retry it on linux once I figure out what /dev/tty.. i need to pass to screen.
ajfisher
@ajfisher
Sep 29 2016 07:34
hmm - not entirely certain what device that's going to present on with Linux - probably all i'd do is run ls /dev/tty and see the diff before and after I plug it in - low tech but should give you the one you're after. To be honest I only played with this once and got it to work and didn't do anything more with it because we opted for BT modules due to better support or true* wifi modules so they would work over network.
noitsme
@noitsme
Sep 29 2016 13:18
ok, thanks for the tip. will try it out!
and also, after my purchase, I realized the BT module is better - but tried purchasing it and its either expensive or too-slow shipping.