Jump to content

Axpert USB


Gnome

Recommended Posts

Hi everyone

Has anyone been able to make use of the Axpert USB on a Raspberry Pi or Mac OSX or Linux?

Those operating systems do show the device name as being Serial to USB converter. However I've tried a few ways of accessing it as a Serial Port using Ruby/Python with no luck.

Thanks!

Link to comment
Share on other sites

Almost everybody uses a PL2303 or a ftdi these days. Most operating systems have drivers bundled for those. It's just a matter of getting the port right.

The drivers on some versions of OSX has a baud rate issue where it uses the wrong baud rate. You then have to install the ftdi drivers, AND you also have to kextunload and kextload the right one. OSX is by far the biggest thorn in my side when it comes to ftdi.

Link to comment
Share on other sites

40 minutes ago, Chris Hobson said:

I think Manie and Tinker have managed to get that right.

I noticed, anyone willing to share how?

From what I can tell they ask the user to create a udev rule. That alone does not work for me. I lost interest in fiddling with it, since it distracts from actual interesting work, like software. But it would be nice to figure it out.

27 minutes ago, plonkster said:

Almost everybody uses a PL2303 or a ftdi these days. Most operating systems have drivers bundled for those. It's just a matter of getting the port right.

The drivers on some versions of OSX has a baud rate issue where it uses the wrong baud rate. You then have to install the ftdi drivers, AND you also have to kextunload and kextload the right one. OSX is by far the biggest thorn in my side when it comes to ftdi.

I have PL2303 and pretty happy with it. I was simply trying to determine if it was possible to skip the PL2303 requirement as a matter of supporting all the options

I actually didn't have any issue in Mac OSx. I do all my dev work on a Macbook Pro. I did need to install a driver from here: http://www.prolific.com.tw/US/ShowProduct.aspx?p_id=229&pcid=41

Link to comment
Share on other sites

51 minutes ago, Gnome said:

I actually didn't have any issue in Mac OSx. I do all my dev work on a Macbook Pro. I did need to install a driver from here: http://www.prolific.com.tw/US/ShowProduct.aspx?p_id=229&pcid=41

I've had issues with the FTDI chips. OSX ships with a driver, and that driver is good at low speeds, but we have devices that need to dump lots of data so we turn them up to 3mbaud. The FTDI actually supports that. It works perfectly on Linux and Windows. On the mac, it breaks unless you install the driver... and even then it's not always plain sailing. Since it is proprietary code, we're up the creek and we just hack it until it works.

We noted some other interesting speed things. Even though we have the speed cranked all the way up, the actual throughput is nowhere near 3mbaud. Linux gets the best speed, at almost 1mbaud, but the Mac and Windows machines barely manage 500kbaud.

None of these issues apply here though, so you could quite likely get away without installing any additional drivers.

Link to comment
Share on other sites

Curious, I couldn't get it running without installing the driver I linked.

I only really do development on my Mac. Mac is a bit expensive to be hooking up to any kind of device long term. I assume you guys are making a consumer device which requires you to support Mac. Otherwise I'm curious why even care about Mac :)

IIRC you develop in Python at your org right? (ie> are you essentially getting cross OS for free?)

Link to comment
Share on other sites

We have ARM-based data-collection devices and a software package that can download data from those devices. That software runs on Linux, OSX and Windows. We have to support OSX as many of the researchers and developers use that.

Link to comment
Share on other sites

Ah ok, thought so :)

On the topic however, so I played around a bit with the udev rules.

When I add the following:

ATTRS{idVendor}=="0665", ATTRS{idProduct}=="5161", SUBSYSTEMS=="usb", ACTION=="add", MODE="0666", GROUP="root", SYMLINK+="ttyVoltronic"

I get the following:

lrwxrwxrwx 1 root root 7 Oct 26 10:35 /dev/ttyVoltronic -> hidraw0

I've tried using hidraw0 as a Serial Port before, however: 

SerialPort.new('/dev/hidraw0')
ArgumentError: not a serial port
    from /home/inverter/.rvm/gems/ruby-2.3.0/gems/serialport-1.3.1/lib/serialport.rb:25:in `create'
    from /home/inverter/.rvm/gems/ruby-2.3.0/gems/serialport-1.3.1/lib/serialport.rb:25:in `new'
    from (irb):2
    from /home/inverter/.rvm/rubies/ruby-2.3.0/bin/irb:11:in `<main>'

Guess I'll need to do a bit more research. I was expecting it to work simply as a TTY but I guess they are adding a layer on top of that.

Link to comment
Share on other sites

Not wanting to waste too much time on this, but I doubt I'll get anywhere without actually making use of the Cypress SDK which is found here:

http://www.cypress.com/documentation/software-and-drivers/usb-serial-software-development-kit

I downloaded it and was able to get it running on my RPi and communicate to the Axpert. However, it would require the development of an entire abstraction layer.

:sigh: Couldn't they have just used the PL2303 :P

Link to comment
Share on other sites

Ah ok, thought so default_smile.png
On the topic however, so I played around a bit with the udev rules.
When I add the following:
ATTRS{idVendor}=="0665", ATTRS{idProduct}=="5161", SUBSYSTEMS=="usb", ACTION=="add", MODE="0666", GROUP="root", SYMLINK+="ttyVoltronic"

I get the following:

lrwxrwxrwx 1 root root 7 Oct 26 10:35 /dev/ttyVoltronic -> hidraw0

I've tried using hidraw0 as a Serial Port before, however: 

SerialPort.new('/dev/hidraw0')ArgumentError: not a serial port    from /home/inverter/.rvm/gems/ruby-2.3.0/gems/serialport-1.3.1/lib/serialport.rb:25:in `create'    from /home/inverter/.rvm/gems/ruby-2.3.0/gems/serialport-1.3.1/lib/serialport.rb:25:in `new'    from (irb):2    from /home/inverter/.rvm/rubies/ruby-2.3.0/bin/irb:11:in `<main>'

Guess I'll need to do a bit more research. I was expecting it to work simply as a TTY but I guess they are adding a layer on top of that.


Use SUBSYSTEMS=tty. If I recall correctly. That catches the addition of the /dev/ttyUSBx device which is probably what you want.

Sent from my GT-I9195 using Tapatalk

Link to comment
Share on other sites

On 10/26/2016 at 1:56 PM, Gnome said:

Not wanting to waste too much time on this, but I doubt I'll get anywhere without actually making use of the Cypress SDK which is found here:

http://www.cypress.com/documentation/software-and-drivers/usb-serial-software-development-kit

I downloaded it and was able to get it running on my RPi and communicate to the Axpert. However, it would require the development of an entire abstraction layer.

:sigh: Couldn't they have just used the PL2303 :P

Did you get it right?

Link to comment
Share on other sites

45 minutes ago, AndewJ said:

Did you get it right?

I time boxed it to 1 day. In the end I spent about 3-4 hours on it then lost patience. Haven't spent time on it again.

I feel like using PL2303 is just so much easier and it only costs R170.

I'm coding some other stuff right now, at some point I may take a crack at it again :)

Link to comment
Share on other sites

  • 3 weeks later...

So anyone have a Windows PC and willing to capture some USB output while connected to their device?

Pretty much from the moment it gets connected, running the Voltronic software for 5 minutes and then you can stop.

I've started writing a driver for Linux, but sadly the Cypress SDK is proving less than useful. So it seems like reverse engineering the protocol by capturing it is the simpler solution.

Sadly I don't have a Windows PC at present :(

The simplest way to capture the USB data is using USBPcap: http://desowin.org/usbpcap/

I can't guarantee I'll be able to get it working but if I do the result will be free to everyone.

I'm considering doing 2 things:

1) Create a Linux compatible driver

2) Create a Ruby library which will be VERY easy to translate to Python. They way both Ruby and Python interface with USB is almost identical.

I feel 2 is more useful because it will be cross platform, so we can have 1 interface that works on all operating systems. Rather than a driver that just work on the Raspberry Pi (or rather Linux).

Link to comment
Share on other sites

Not sure what you trying to achieve. Salarmon and AICC pi already use usb. You talk about a lot of different languages and make things complicated. But good luck to you. No need for drivers ect.

Sent from my SM-G920F using Tapatalk

Link to comment
Share on other sites

16 minutes ago, Manie said:

Salarmon

SolWEB you mean. SolarMON is now SolWEB, unless Edmund wants to continue with SolarMON.

So yes, the USB part has been sorted long time ago on AICC (Windows) and the new AICC Pi. Also sorted on SolarMON and SolWEB, but only for Windows - tablets and Pc Sticks.

Link to comment
Share on other sites

SolWEB you mean. SolarMON is now SolWEB, unless Edmund wants to continue with SolarMON.
So yes, the USB part has been sorted long time ago on AICC (Windows) and the new AICC Pi. Also sorted on SolarMON and SolWEB, but only for Windows - tablets and Pc Sticks.


Haha yes .

Sent from my SM-G920F using Tapatalk

Link to comment
Share on other sites

38 minutes ago, Manie said:

Not sure what you trying to achieve. Salarmon and AICC pi already use usb. You talk about a lot of different languages and make things complicated. But good luck to you. No need for drivers ect.

Sent from my SM-G920F using Tapatalk
 

Reasons:

1) The software doesn't run on any platform

2) The software isn't open source so I can't change anything about how it works

3) Unless I'm mistaken the software eg. AICC is not free

Why should I restrict myself to Windows? Or specifically RPi2, etc.

Of course you don't have to support the effort in which case I would ask that you just avoid the topic :)

Edited by Gnome
Fixed typo
Link to comment
Share on other sites

15 minutes ago, The Terrible Triplett said:

SolWEB you mean. SolarMON is now SolWEB, unless Edmund wants to continue with SolarMON.

So yes, the USB part has been sorted long time ago on AICC (Windows) and the new AICC Pi. Also sorted on SolarMON and SolWEB, but only for Windows - tablets and Pc Sticks.

Sort of my point, I would simply like a open source driver that works on every operating system.

If you want to use it on a RPi, Linux machine or your Arduino, you are free to do so.

At present the options are restricted to development by a few people.

I think an open source solution that anyone can tinker with is the ideal world with this sort of thing.

That allows anyone to contribute without everyone reinventing the wheel.

Link to comment
Share on other sites

Either way I found an old laptop in my apartment with Windows on it and captured the output, it is actually really easy.

I'll draw up a specification document that explains the protocol as soon as I've looked at it.

USB is over complicated (this needed to be said)

Link to comment
Share on other sites

If we want we can run AICC on any platform. No problem. There are a lot of open-source available . Also no softwere give you the ability to change source code and constomize it for your need.

Also install windows on vm and do the sniffing if you want. I doubt you will find people here running sort of sniffers and provide it here. Just use a protocal . No need for tracers. Protocals docs are availble

No one is retricting you. You can try and do what you like with your software.

This is advice but take it like you want.


Sent from my SM-G920F using Tapatalk

Link to comment
Share on other sites

5 minutes ago, Manie said:

If we want we can run AICC on any platform. No problem. There are a lot of open-source available . Also no softwere give you the ability to change source code and constomize it for your need.

Also install windows on vm and do the sniffing if you want. I doubt you will find people here running sort of sniffers and provide it here. Just use a protocal . No need for tracers. Protocals docs are availble

No one is retricting you. You can try and do what you like with your software.

This is advice but take it like you want.


Sent from my SM-G920F using Tapatalk
 

Well having access to the source code allows customizing it.

Again AICC is not free right :)

I was able to capture the data using USBPCap. I'm not sure what you mean by the protocol docs? You mean the USB protocol documents are available?

Can you point me to it?

I found the Cypress SDK but it really wasn't all the useful.

However when I look at the data in USBPCap it is really easy to see what is happening, eg. calling _URB_CONTROL_TRANSFER with QPI.

I'm 100% for listening and taking advice.

However I don't believe I'm 100% happy with the software that is available today simply because:

1) It isn't free

2) The source code isn't available

My ends aren't to fight anyone over it or make some kind of breakthrough.

Just going my way :) 

 

Link to comment
Share on other sites

20 minutes ago, Gnome said:

At present the options are restricted to development by a few people.

YES!!! I tried that. One reader for all devices, what user does with the data is their decision.

But, we are South Africans. :D

 

Link to comment
Share on other sites

3 minutes ago, Gnome said:

1) It isn't free

2) The source code isn't available

It is quite simple. The hours we have put in, AICC and SolWEB, trust me, reading the data is one thing, getting it tested and stable is the 2nd issue.

3rd is what happens with the data is the fun part.

Then there is more development to switch inverters.

Ask Manie, and my guys ... it is a LOT of hours with the potential of no ROI.

... then the next person comes around and say, hey, I have this device, can you add it  please ... circle starts again. :D

Link to comment
Share on other sites

YES!!! I tried that. One reader for all devices, what user does with the data is their decision.
But, we are South Africans. default_biggrin.png
 


TTT will be kind enough to open his source code for all to tinker. However AICC wil not be open and beleave Microsoft products is not aswell.

Good like with the fight

Sent from my SM-G920F using Tapatalk

Link to comment
Share on other sites

2 minutes ago, The Terrible Triplett said:

It is quite simple. The hours we have put in, AICC and SolWEB, trust me, reading the data is one thing, getting it tested and stable is the 2nd issue.

3rd is what happens with the data is the fun part.

Then there is more development to switch inverters.

Ask Manie, and my guys ... it is a LOT of hours with the potential of no ROI.

... then the next person comes around and say, hey, I have this device, can you add it  please ... circle starts again. :D

I'm a software developer by day :P

So I sort of get the pains of developing an application.

Long before any of the software available now on this forum I had already written something to interact with my Axpert: https://rubygems.org/gems/axpert_rs232/versions/1.0.3

I haven't worked on it for a over a year and simply used that with an HTTP server to allow capturing of data.

Thereafter I built some stuff to make it use SQLite and dropped that due to filesystem lifespan on the RPi.

This was long before AICC or any other software was a thing.

I never released it here as product simply because I didn't want to deal with fixing it for others.

But I certainly don't have qualms about sharing it and allow others to do their own thing.

Hopefully that clarifies my position on it slightly :P

I'm not really trying to compete, I simply like doing this as a hobby and I release it publicly.

Would love to see what you've written however, especially if you've solved the USB problem (outside Windows especially).

I'm planning to create a wrapper in Python or Ruby that will allow you to use the USB on any operating system.

That was sort of the point of this topic.

I would simply publish that the same way I published that RubyGem.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...