Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bluetooth does not seem to work with EV3 #10

Open
fcarsten opened this issue Apr 3, 2019 · 5 comments
Open

Bluetooth does not seem to work with EV3 #10

fcarsten opened this issue Apr 3, 2019 · 5 comments

Comments

@fcarsten
Copy link

fcarsten commented Apr 3, 2019

I run ev3duder on Windows 10 64Bit which is connected via Bluetooth to an EV3 HW: 0.60, FW: 1.09H .

The Bluetooth connection works fine with the Mindstorm software. If I run ev3duder however, it hangs at "Checking reply":

PS C:\Users\carsten> C:\ev3\uploader\ev3duder.exe --serial=COM7 ls
00 08 00 00 00 01 99 00 04 2f 00
Checking reply:

@WingSMC
Copy link

WingSMC commented Apr 3, 2019

Consider using the new ev3 firmware(the one which is available on the microsoft make code website) and the new windows driver, which enables uploading files directily via the file explorer.

@a3f
Copy link
Member

a3f commented Apr 8, 2019

It hangs inside HIDAPI, which is doubly strange, because we specify a 2 second timeout, so it should've just failed if nothing happens..

As for the actual issue, sorry, no idea. Maybe newer firmware versions speak a different protocol? I didn't know about the Windows driver, but it sounds like the better alternative. You can always trace the USB/HID messages exchanged between the EV3 and the Windows driver if you want ev3duder to support them..

@JakubVanek
Copy link
Contributor

I am too unable to use Bluetooth on Linux. I don't know if the issue is with the protocol, but from the EV3 sources it seems it should still behave the same. ev3duder was only able to read() two bytes from the /dev/rfcommN device. This was the case for both separate and combined reading of the length field.

I think using rfcomm sockets instead may help with this, but that is linux-specific.

@JakubVanek
Copy link
Contributor

The Linux issue is likely different, opening #27 for it.

@germanicianus
Copy link

@fcarsten, this issue has most likely been fixed with #40.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants