PINNED - Info on PROGRAMMING PGDT and others

Power wheelchair board for REAL info!

POWERCHAIR MENU! www.wheelchairdriver.com/powerchair-stuff.htm

Re: DIY PGDT interface for OEM PROGRAMMING

Postby Burgerman » 30 Jul 2014, 19:28

Ideally you need oem which they will refuse to sell you. And:

>>>Hopefully they wont charge an arm and a legl

No, testicles.
User avatar
Burgerman
Site Admin
 
Posts: 71106
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: DIY PGDT interface for OEM PROGRAMMING

Postby WDMSetc » 30 Jul 2014, 20:45

Burgerman wrote:Ideally you need oem which they will refuse to sell you. And:

>>>Hopefully they wont charge an arm and a legl

No, testicles.


As in: "(look, ma!) no testicles!"
WDMSetc
 
Posts: 89
Joined: 23 Jul 2014, 02:26
Location: SW USA

Re: DIY PGDT interface for OEM PROGRAMMING

Postby garriew » 01 Aug 2014, 05:00

I downloaded the dealer version of R-Net to connect to my chair, does it need a dongle?
garriew
 
Posts: 334
Joined: 06 Dec 2013, 07:11
Location: Mt Vernon, IL USA

Re: DIY PGDT interface for OEM PROGRAMMING

Postby Burgerman » 01 Aug 2014, 09:04

It wont allow you to do much. Yes it needs a dongle.
User avatar
Burgerman
Site Admin
 
Posts: 71106
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: DIY PGDT interface for OEM PROGRAMMING

Postby woodygb » 01 Aug 2014, 10:11

The R-Net software is not ... as far as I'm aware ...dealer level .... the level of access provided by the software is governed by the DONGLE.
The DONGLE comes in at least two types R-net PC Prg Dealer and OEM R-net PC Prg OEM
User avatar
woodygb
 
Posts: 7128
Joined: 12 Mar 2011, 18:45
Location: Bedford UK

Re: DIY PGDT interface for OEM PROGRAMMING

Postby garriew » 01 Aug 2014, 16:39

woodygb wrote:The R-Net software is not ... as far as I'm aware ...dealer level .... the level of access provided by the software is governed by the DONGLE.
The DONGLE comes in at least two types R-net PC Prg Dealer and OEM R-net PC Prg OEM

I downloaded it from Permobils site and the bottom says "Permobil Dealer Version" Something like that.

It looks like I'm going to be stuck doing what the DME can with their handheld.
garriew
 
Posts: 334
Joined: 06 Dec 2013, 07:11
Location: Mt Vernon, IL USA

Re: DIY PGDT interface for OEM PROGRAMMING

Postby Burgerman » 01 Aug 2014, 20:21

R-Net can have and maybe does have, what's called OBP which is a programmer embedded in the system. You may need a code or something to access it. It cant do all the useful stuff the OEM level PC programmer can, but it can do as much as the dealer version.

http://www.pgdt.com/Products/Programmer ... mming.aspx

The chair manufacturer will likely rip you off for the privilege.
User avatar
Burgerman
Site Admin
 
Posts: 71106
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: DIY PGDT interface for OEM PROGRAMMING

Postby ex-Gooserider » 05 Aug 2014, 12:01

WDMSetc wrote:
ex-Gooserider wrote:There have been some efforts / success at hacking into the input side of the system, i.e. by opening up the joystick pod and splicing into the wiring between the joystick and the controller electronics, but that is kind of sketchy for a lot of reasons. However at least the options of what signals are present and how to tap into them are limited and fairly easy to identify...


I had thought putting a logic/protocol analyzer on the signals to/from these devices could go a long way to capturing the details of the protocol. I imagine the manufacturers DON'T try to "encrypt" their communications but, rather, rely on "security by obscurity" -- just don't TELL anyone what information is being exchanged (but, don't take pains to DISGUISE it, either!) Or, make trivial efforts to hide data (e.g., HP makes a "Secure Web Console" -- did you notice the word SECURE in that description? -- that "encrypts" the traffic that it passes down the network with a simple/trivial substitution cipher: XOR each character/byte with a particular CONSTANT! And this is "secure"???)

If so, conceivably moving the stick left, right, up, down... pressing the horn button... commanding any additional actuators, etc. and observing the data exchanged could go a long way to sorting out what is going on inside the "system".

[People have done far more with systems that were *designed* to be "secure"!]

As mentioned, I will try to pick up some additional "power modules" and "joystick controllers" so I can "sacrifice" a few. Short of deencapsulating actual components, it may be possible to tap into interfaces (e.g., JTAG) that are present to facilitate development and/or production.


Essentially there are two places to intercept / inject signals - either in the cable between the modules - which is going to be manufacturer specific digital data - CANbus in some cases (and not that CANbus says how the data is handled, but not what the format of the actual commands are - so those can / will be different...) and between the actual joystick and other buttons on the joystick pod - which are simple analog signals - on/off for the push buttons, and some sort of analog voltage swing on the joystick can. While there will be some variation in those signals, it would be a fairly simple matter to adjust at that point for different manufacturers - i.e. the biggest difference in the joystick cans is the exact center-voltage and swing range they use...

I agree that it is probably easier to start from scratch for most of the control stack the way that Lenny is doing. I would consider staying with a good commercial motor controller simply because high power motor control is difficult to do well, and I think that if you avoid leaving more than controlling the basic functions to the controller box, then it shouldn't be terribly hard to switch the box if the existing product gets changed... I understand your concern about getting hosed by surpise changes on the COTS component supplier side, but there is also the tradeoff between full control of the component chain and not simply spending a lot of time reinventing the wheel...


Any vendor on which you rely leaves you vulnerable. Having to redesign *your* system simply because a vendor opted to make a change -- for whatever reason -- to *his* "component" is a terrible way to run a business (even if it's not a business, per se). Vendors seldom tell you, in advance, that a change is coming. And, may implement a change without telling you ("Gee, why do the new chairs all seem to have this problem? Have WE changed something? Let's see... no, not us! Any change notices from our suppliers??")
<snip>


Been there, done that, got the T-shirt.... OTOH, short of building your own silicon foundry, there is no way to avoid being at the mercy of the supplier somewhere along the line.... IMHO the key is to make the design as "modular" as possible so that an upstream change will have minimal impact. Also to choose parts that have a lot of "inertia" - where upstream would have difficulty changing them without a lot of market push-back... Atmel sells a ton of 328 micros such as are used in the Arduino world - they would be foolish to drop them or change them (and the Open Source Hardware world would be quick to sound the alarm and find fixes if they did...)

As an example: Currently Lenny and others are putting a lot of effort into writing a script for the Roboteq, using it's on-board micro-controller. This works but does lock them to that controller, and leaves them vulnerable to any changes that Roboteq may make to their interface (Including potentially fixing bugs that Lenny has found and reported...)

OTOH, if they had chosen to implement the script in an Arduino based box, who's design they control, and simply output pure motor control signals to the Roboteq, then it would be fairly easy to switch to some other brand controller simply by re-writing the actual control part of the software....

It is also why I'm a big advocate of Free / Open software - if you have the source, the manufacturer can't change it out from under you...

Of the various commercial systems out there, I would say the most "hacked on" here are:

1. The Penny and Giles / P&G / PGDT "Pilot+" series,

I think that is what is present on the chair I currently rescued. The controls bear markings "PGDT".


Not necessarily - from other comments it sounds more like a VR-2 system... P&G has at least the Pilot, Pilot+, VR-2, and R-net systems, plus more variants on scooters....

which is what BM has used on some of his chairs, and for which the OEM level programmer has "escaped into the wild".

Where can I find this? Or, would it not benefit me?


Ask around- it will appear in your inbox... (if it hasn't already) 8-) There are threads elsewhere that describe how to make the needed cable to go from your PC to the chair... I don't know how much benefit it will offer for you in hacking the electronics, but it may help with seeing some of the parameters that are used in programming a chair.

There has been some different projects to modify their electronic innards as well - Woody has built an RC interface that talks to it, and I'm currently working out how to install a speed pot in pods that don't have one.


For the "joystick controller", I think I owuld be happy just to be able to use it as an "input device" -- and not have to repackage my own electronics to fit in that enclosure *just* to have a means of mounting the joystick in a convenient location. But, that assumes there is no "processing" of the joystick's motions within those (PGDT) electronics. Otherwise, it may be easier to just gut the box and lay out a new board that interfaces to the joystick directly.

The Pilot+ joystick module has quite a bit of 'smarts' in it, relatively speaking... It has at least one large microprocessor and a fairly well packed board. Other modules will be similar since they all do more or less the same sort of things. They take the inputs from the Joystick can itself, as well as any other switches and buttons, and turn them into the protocol that goes over the line to the rest of the modules, and recieve any data needed for display - battery meter, speed settings, all the crap on the display screen (if any) that comes over the cable and translate it back for output... At least some level of data processing in the pod is needed just to minimize the wiring to the rest of the system, and to go from analog signals that are easily disrupted to more 'bullet-proof' digital data - which is probably the biggest reason to use CANbus in anything you create, as that is arguably the most robust way to do the data networking between modules.

2. The Dynamic DX series that Lenny has been using on Rachi's chair, but which needs a proprietary dongle to actually make any programming changes, however there are known places where one can purchase the dongles (though they are not cheap...)


So, there is no advantage/disadvantage to the PGDT vs. Dynamic from a typical user's point of view (unable to "program" *either* of them)
More or less - there are some details at the edges about the nature of some of the interface connections, or extreme performance tuning, but mostly it's a Ford vs. Chevy sort of thing... There can be some interface details differences that will make a user like one more than the other, but that is a personal preference thing most of the time... Most chair makers will tend to use one system or the other on their chairs (though usually you can specify something else for a price) and often users don't even KNOW what system they are using...

3. It is best to stay FAR away from any Pride / Quantum products, as they are probably the worst in the industry for NOT allowing access to programming tools and information. (not to mention poorer than average build quality and other issues.)


I see I will have to do more research. I had thought Pride was a reseller/dealer -- not a manufacturer. Ditto "Mobility"

Nope - not sure who "Mobility" is, but Pride is a manufacturer, that sells chairs under both the Pride and Quantum brands. "Pride" chairs tend to be the low end "granny-mobiles" for people that have mobility challenges but don't need a lot of custom seating or other fancy support, while Quantum chairs are more targetted towards the "rehab" end of things for people that have to have custom seating and extra functions like tilt/recline, and so on...

Note that none of the "chair manufacturers" actually make all that much - essentially they are assemblers that make a frame and maybe a wiring harness, and hang 3rd party sourced motors, control systems, seats, and so on off of the frame....
User avatar
ex-Gooserider
 
Posts: 6232
Joined: 15 Feb 2011, 06:17
Location: Billerica, MA. USA

Re: DIY PGDT interface for OEM PROGRAMMING

Postby expresso » 10 Aug 2014, 23:49

hi - would anyone know how i can get my programming cable to work again - i have the cable and serial to usb connection - for my quickie P222 - Pilot +

i had it working fine when i was running Vista - i have recently upgraded to Windows 8 - Vista was really crap - i reinstalled the software - that was fine

but now i went to use the cable and it keeps telling me - COMMS INACTIVE - i havnt a clue now what excatly i did last time this happened when i first got it -

i know i had it working on only ONE Of my 3 usb ports on my laptop - but now i cant get it work on any of them -

if anyone knows what i can try - or had the same issue with Windows 8 - any input would be great -

thanks
expresso
 
Posts: 11985
Joined: 10 May 2010, 03:17

Re: DIY PGDT interface for OEM PROGRAMMING

Postby woodygb » 10 Aug 2014, 23:56

Whose make of lead ... one of mine?

If so ... uninstall the present drivers....then go here and follow the instructions ... http://www.crercc.com/comport.html
User avatar
woodygb
 
Posts: 7128
Joined: 12 Mar 2011, 18:45
Location: Bedford UK

Re: DIY PGDT interface for OEM PROGRAMMING

Postby expresso » 11 Aug 2014, 00:05

woodygb wrote:Whose make of lead ... one of mine?



hi - no i got it from P&G directly - and its worked fine - after i had to do something on some port or comms - my laptop HP - has 3 usb ports - i had one which worked - i was running Vista - i had to redo my laptop and installed Wins 8 - works better everything is great but now i went to use the cable and cant get it to work -

i never tried it on my desktop before - but that has windows 8 also - any ideas what i can try - i know the cable works - its the computer usb ports - comms inactive when i start the program
expresso
 
Posts: 11985
Joined: 10 May 2010, 03:17

Re: DIY PGDT interface for OEM PROGRAMMING

Postby woodygb » 11 Aug 2014, 00:11

The problem is likely with the USB - Serial adaptor.

Any chance of looking in Device manager and seeing if the USB - Serial adaptor is shown as installed / not installed correctly ?


Just in case .... http://kb.linksys.com/Linksys/GetArticl ... onverted=0
User avatar
woodygb
 
Posts: 7128
Joined: 12 Mar 2011, 18:45
Location: Bedford UK

Re: DIY PGDT interface for OEM PROGRAMMING

Postby expresso » 11 Aug 2014, 00:19

i dont see anything wrong in device manager - and it shows USB serial convertor in devices - shows as working correctly -

i deleted it before and restarted - nothing changed - i will try my other usb ports to check again -
expresso
 
Posts: 11985
Joined: 10 May 2010, 03:17

Re: DIY PGDT interface for OEM PROGRAMMING

Postby woodygb » 11 Aug 2014, 00:21

From memory the approved USB - Serial lead has a FTDI chip ... so if device manager mentions USB <-> Serial & FTDI try this installation guide

http://www.ftdichip.com/Support/Documen ... dows_8.pdf


Edit - What Com Port number has Windows Device manager assigned to the USB <-> Serial ?

Only numbers 1-8 are acceptable by the PGDT Software.
User avatar
woodygb
 
Posts: 7128
Joined: 12 Mar 2011, 18:45
Location: Bedford UK

Re: DIY PGDT interface for OEM PROGRAMMING

Postby expresso » 11 Aug 2014, 00:25

i checked and it does show that chip -- i downloaded the guide - alot of pages !! i will read it and see if i can do what it says

it shows as working - in device manager
expresso
 
Posts: 11985
Joined: 10 May 2010, 03:17

Re: DIY PGDT interface for OEM PROGRAMMING

Postby woodygb » 11 Aug 2014, 00:26

I'll repost my edit...just in case you haven't seen it.

What Com Port number has Windows Device manager assigned to the USB <-> Serial ?

Only numbers 1-8 are acceptable by the PGDT Software
.

and then once a number between 1 and 8 is assigned ...YOU must also select that installed COM Port number in the PGDT Software.
User avatar
woodygb
 
Posts: 7128
Joined: 12 Mar 2011, 18:45
Location: Bedford UK

Re: DIY PGDT interface for OEM PROGRAMMING

Postby woodygb » 11 Aug 2014, 00:34

I have found this little utility helpful in seeing what is plugged in and the related Com Port number.
http://www.crercc.com/files/driver/FindComPort.exe
User avatar
woodygb
 
Posts: 7128
Joined: 12 Mar 2011, 18:45
Location: Bedford UK

Re: DIY PGDT interface for OEM PROGRAMMING

Postby expresso » 11 Aug 2014, 00:39

ok i think that was it - it was comm 4 in device manager and it was comm 1 in the software - i didnt think of the software end -

it works now - but i did install some of those drivers i downloaded - from FTDI site - i will reboot and check it again - to make sure its still working


thanks !!! -
expresso
 
Posts: 11985
Joined: 10 May 2010, 03:17

Re: DIY PGDT interface for OEM PROGRAMMING

Postby woodygb » 11 Aug 2014, 00:40

Your welcome.
User avatar
woodygb
 
Posts: 7128
Joined: 12 Mar 2011, 18:45
Location: Bedford UK

Re: DIY PGDT interface for OEM PROGRAMMING

Postby expresso » 11 Aug 2014, 00:50

you know whats strange - i am actually using my old P220 - my 222 is charging now - i think its working but i though when you plug it in the chair and turn it on - the joystick lights would be flashing ? thats how i remember it -

but i just noticed now - that they dont and chair actually works even with the cable plugged in - i was able to read from the controller this way also -

i didnt change any thing or try to write to it - since this is not the chair i wanted to adjust right now - is that normal ?
expresso
 
Posts: 11985
Joined: 10 May 2010, 03:17

Re: DIY PGDT interface for OEM PROGRAMMING

Postby woodygb » 11 Aug 2014, 00:58

It would seem that the inhibit is either not working or setup differently on the chair that moves with the program cable plugged in .... no big deal just don't forget to disconnect it!
User avatar
woodygb
 
Posts: 7128
Joined: 12 Mar 2011, 18:45
Location: Bedford UK

Re: DIY PGDT interface for OEM PROGRAMMING

Postby expresso » 11 Aug 2014, 01:03

it seems to work - it dosnt blink on my joystick when i connect to the program - or read from my controller - but when writing to my controller

it then scrolls left to right fast on the joystick - so its working - just strange that i remembered it different before - it used to blink once i connected to my joystick and turned on the chair -

good thing that its working and my other usb ports also work now -
expresso
 
Posts: 11985
Joined: 10 May 2010, 03:17

Re: DIY PGDT interface for OEM PROGRAMMING

Postby expresso » 11 Aug 2014, 01:05

woodygb wrote:It would seem that the inhibit is either not working or setup differently on the chair that moves with the program cable plugged in .... no big deal just don't forget to disconnect it!



yeah that i wont forget to do - but i do remember it flashing from the start - is there a setting i may have touched in the program ?

it blinks scrolling fast when i write to it - just not when i read from it - or just plug it in -

anyway - thanks alot - i was getting worried - :)
expresso
 
Posts: 11985
Joined: 10 May 2010, 03:17

Re: DIY PGDT interface for OEM PROGRAMMING

Postby woodygb » 28 Aug 2014, 12:43

takenaback wrote:I managed to get somebody with some soldering skill to try and fix the cables. Got the Kenwood one working somewhat but it comes up with (TRIPPED) when it is plugged in. I guess this is more than likely a problem with the cable?

Cheers


IF the software say's COMMS ACTIVE then the cable is fine.

TRIPPED .... which has been read FROM the controller ...indicates an INHIBIT condition ....
User avatar
woodygb
 
Posts: 7128
Joined: 12 Mar 2011, 18:45
Location: Bedford UK

Re: DIY PGDT interface for OEM PROGRAMMING

Postby frezamu » 19 Sep 2014, 21:36

Greetings ask for help with the following problem with a pilot control of it being old single item the problem is that after changing the potentiometer that regulates the speed control I stay blinking led the first eight and the developer (Qtronix) give me eeprom corrupted memory code, change the eeprom and I are all blinking red lED light up green rapidly cleared from red to green just not returned, change several times eeeprom memory and so I had another card repaired and put eeprom memories stay the same and the LEDs light up red to green faster than I do or what that code means I appreciate that I can help
frezamu
 
Posts: 8
Joined: 01 Jul 2014, 16:38

Re: DIY PGDT interface for OEM PROGRAMMING

Postby woodygb » 19 Sep 2014, 21:45

What you've written is difficult to understand.

Do these flash codes help?
Do any of them match your error?

http://support.pgdt.com/Online-Diagnost ... Codes.aspx
User avatar
woodygb
 
Posts: 7128
Joined: 12 Mar 2011, 18:45
Location: Bedford UK

Re: DIY PGDT interface for OEM PROGRAMMING

Postby frezamu » 19 Sep 2014, 22:05

Greetings thanks for your reply I try to explain the control was good change the potentiometer goes in the back of the control that gives minimum and maximum speed when relit control did not work so connect the programmer qtronixy said mistake eeepron damaged replace the eeprom for a new control stick flashing from red to green quickly put another memory of another control and the same but in the Qtronix no error if I disconnect an engine or brakes or connect the charger gives me the correct code fails example, the LEDs light up according to the fault but the control does not work
My question the EEPRON have a factory code or can no longer be repaired
Thanks for any suggestions
frezamu
 
Posts: 8
Joined: 01 Jul 2014, 16:38

Re: DIY PGDT interface for OEM PROGRAMMING

Postby woodygb » 19 Sep 2014, 22:22

The flash code suggests that you have a "displaced joystick"... so I suspect that the problem is joystick related.

You could check that the voltage output at neutral is centered @ 2.5v .
User avatar
woodygb
 
Posts: 7128
Joined: 12 Mar 2011, 18:45
Location: Bedford UK

Re: DIY PGDT interface for OEM PROGRAMMING

Postby frezamu » 19 Sep 2014, 22:43

Thank led blink like when the joystick is moved but the flicker is much faster when I move the joystick control and turn on flash slowly but shifted to the center and start flashing fast super fast plate change this and other micro locate the perfect damage in micro plate which change the eeprom
frezamu
 
Posts: 8
Joined: 01 Jul 2014, 16:38

Re: DIY PGDT interface for OEM PROGRAMMING

Postby frezamu » 19 Sep 2014, 22:44

This code is not on the fault codes
frezamu
 
Posts: 8
Joined: 01 Jul 2014, 16:38

PreviousNext

Return to Everything Powerchair

Who is online

Users browsing this forum: acid_coke, emilevirus, jehan and 591 guests

 

  eXTReMe Tracker