Products for USB Sensing and Control
Display all prices in:
AmEx
  Acceptance Mark  
ROHS
It is currently Mon Jun 17, 2013 9:40 pm

Board index » Programming - General and OS » Linux

All times are UTC - 7 hours [ DST ]



Post new topic Reply to topic  Page 2 of 3
  [ 38 posts ]  Go to page Previous  1, 2, 3  Next
  Print view Previous topic | Next topic 
Author Message
sgm
 Post subject: Results with 2.6 kernel
PostPosted: Sun Jan 27, 2008 8:22 pm 
Offline
Fresh meat

Joined: Fri Jan 25, 2008 5:34 pm
Posts: 3
I retrieved and compiled the latest 'kamikaze' source from OpenWRT and installed 2.6 on the Asus. The RFID phidget works, but it's not quite right.

First, I tried using libphidget as a shared library, like I had done with 2.4. For some reason, that didn't work at all. The test application just hangs immediately. I fiddled with it for a while without success.

So, I built the test app using libphidget as a static library. Finally, that worked for reading tags -- almost. It generates the OnTag event, but not the OnTagLost event. I suppose I can use it this way, but it's disconcerting.

Here's the phidgets log from scanning three tags:

Code:
Sat Jan  1 02:53:40 2000,1024,"clog.c(46)",INFO,"Enabling logging"
Sat Jan  1 02:53:40 2000,1026,"cusblinux.c(346)",INFO,"New device in CUSBBuildList: 002*Ü·Ì*H"
Sat Jan  1 02:53:40 2000,1026,"cusblinux.c(437)",WARN,"usb_get_driver_np failed with error code: -61 "No data available""
Sat Jan  1 02:53:40 2000,1026,"cusblinux.c(249)",ERR,"usb_get_string_simple failed in CUSBGetDeviceCapabilities with error code: -32 "Broken pipe""
Sat Jan  1 02:53:40 2000,1026,"cusblinux.c(481)",ERR,"CUSBGetDeviceCapabilities returned nonzero code: 3"
Sat Jan  1 02:53:40 2000,2051,"cthread.c(281)",INFO,"WriteThread running"
Sat Jan  1 02:53:40 2000,2051,"cthread.c(307)",INFO,"WriteThread exiting normally (Not Needed for this device)"
Sat Jan  1 02:53:40 2000,3076,"cphidgetrfid.c(309)",INFO,"tagTimerThread running"
Sat Jan  1 02:53:40 2000,3076,"cphidgetrfid.c(355)",INFO,"tagTimerThread exiting normally"
Sat Jan  1 02:53:40 2000,4101,"cthread.c(184)",INFO,"ReadThread running"
Sat Jan  1 02:53:41 2000,4101,"cusblinux.c(179)",VERBOSE,"usb_interrupt_read timeout: -145 "Connection timed out""
Sat Jan  1 02:53:41 2000,4101,"cthread.c(260)",VERBOSE,"CUSBReadPacket expected time out"
Sat Jan  1 02:53:41 2000,4101,"cusblinux.c(179)",VERBOSE,"usb_interrupt_read timeout: -145 "Connection timed out""
Sat Jan  1 02:53:41 2000,4101,"cthread.c(260)",VERBOSE,"CUSBReadPacket expected time out"
Sat Jan  1 02:53:42 2000,4101,"cusblinux.c(179)",VERBOSE,"usb_interrupt_read timeout: -145 "Connection timed out""
Sat Jan  1 02:53:42 2000,4101,"cthread.c(260)",VERBOSE,"CUSBReadPacket expected time out"
Sat Jan  1 02:53:42 2000,4101,"cusblinux.c(179)",VERBOSE,"usb_interrupt_read timeout: -145 "Connection timed out""
Sat Jan  1 02:53:42 2000,4101,"cthread.c(260)",VERBOSE,"CUSBReadPacket expected time out"
Sat Jan  1 02:53:43 2000,4101,"cusblinux.c(179)",VERBOSE,"usb_interrupt_read timeout: -145 "Connection timed out""
Sat Jan  1 02:53:43 2000,4101,"cthread.c(260)",VERBOSE,"CUSBReadPacket expected time out"
Sat Jan  1 02:53:43 2000,4101,"cusblinux.c(179)",VERBOSE,"usb_interrupt_read timeout: -145 "Connection timed out""
Sat Jan  1 02:53:43 2000,4101,"cthread.c(260)",VERBOSE,"CUSBReadPacket expected time out"
Sat Jan  1 02:53:45 2000,4101,"cusblinux.c(179)",VERBOSE,"usb_interrupt_read timeout: -145 "Connection timed out""
Sat Jan  1 02:53:45 2000,4101,"cthread.c(260)",VERBOSE,"CUSBReadPacket expected time out"
Sat Jan  1 02:53:45 2000,4101,"cusblinux.c(179)",VERBOSE,"usb_interrupt_read timeout: -145 "Connection timed out""
Sat Jan  1 02:53:45 2000,4101,"cthread.c(260)",VERBOSE,"CUSBReadPacket expected time out"
Sat Jan  1 02:53:46 2000,4101,"cusblinux.c(179)",VERBOSE,"usb_interrupt_read timeout: -145 "Connection timed out""
Sat Jan  1 02:53:46 2000,4101,"cthread.c(260)",VERBOSE,"CUSBReadPacket expected time out"
Sat Jan  1 02:53:46 2000,4101,"cusblinux.c(179)",VERBOSE,"usb_interrupt_read timeout: -145 "Connection timed out""
Sat Jan  1 02:53:46 2000,4101,"cthread.c(260)",VERBOSE,"CUSBReadPacket expected time out"
Sat Jan  1 02:53:47 2000,4101,"cusblinux.c(179)",VERBOSE,"usb_interrupt_read timeout: -145 "Connection timed out""
Sat Jan  1 02:53:47 2000,4101,"cthread.c(260)",VERBOSE,"CUSBReadPacket expected time out"
Sat Jan  1 02:53:48 2000,4101,"cusblinux.c(179)",VERBOSE,"usb_interrupt_read timeout: -145 "Connection timed out""
Sat Jan  1 02:53:48 2000,4101,"cthread.c(260)",VERBOSE,"CUSBReadPacket expected time out"
Sat Jan  1 02:53:48 2000,4101,"cusblinux.c(179)",VERBOSE,"usb_interrupt_read timeout: -145 "Connection timed out""
Sat Jan  1 02:53:48 2000,4101,"cthread.c(260)",VERBOSE,"CUSBReadPacket expected time out"
Sat Jan  1 02:53:49 2000,4101,"cusblinux.c(179)",VERBOSE,"usb_interrupt_read timeout: -145 "Connection timed out""
Sat Jan  1 02:53:49 2000,4101,"cthread.c(260)",VERBOSE,"CUSBReadPacket expected time out"
Sat Jan  1 02:53:50 2000,4101,"cusblinux.c(179)",VERBOSE,"usb_interrupt_read timeout: -145 "Connection timed out""
Sat Jan  1 02:53:50 2000,4101,"cthread.c(260)",VERBOSE,"CUSBReadPacket expected time out"
Sat Jan  1 02:53:50 2000,4101,"cusblinux.c(179)",VERBOSE,"usb_interrupt_read timeout: -145 "Connection timed out""
Sat Jan  1 02:53:50 2000,4101,"cthread.c(260)",VERBOSE,"CUSBReadPacket expected time out"
Sat Jan  1 02:53:50 2000,4101,"cthread.c(270)",INFO,"ReadThread exiting normally (Phidget detached)"


Installled packages:

Code:
root@OpenWrt:~# ipkg list_installed
base-files-brcm47xx - 12-r10284 -
bridge - 1.0.6-1 -
busybox - 1.8.2-1 -
dnsmasq - 2.40-1 -
dropbear - 0.50-3 -
gdbserver - 6.3-1 -
hotplug2 - 0.9+r102-2 -
iptables - 1.3.8-2 -
kernel - 2.6.23.1-brcm47xx-1 -
kmod-b43 - 2.6.23.1-brcm47xx-1 -
kmod-crypto-aes - 2.6.23.1-brcm47xx-1 -
kmod-crypto-arc4 - 2.6.23.1-brcm47xx-1 -
kmod-crypto-core - 2.6.23.1-brcm47xx-1 -
kmod-diag - 2.6.23.1-brcm47xx-2 -
kmod-input-core - 2.6.23.1-brcm47xx-1 -
kmod-input-evdev - 2.6.23.1-brcm47xx-1 -
kmod-ipt-nathelper - 2.6.23.1-brcm47xx-1 -
kmod-mac80211 - 2.6.23.1-brcm47xx-1 -
kmod-ppp - 2.6.23.1-brcm47xx-1 -
kmod-pppoe - 2.6.23.1-brcm47xx-1 -
kmod-switch - 2.6.23.1-brcm47xx-1 -
kmod-usb-core - 2.6.23.1-brcm47xx-1 -
kmod-usb-ohci - 2.6.23.1-brcm47xx-1 -
kmod-usb-uhci - 2.6.23.1-brcm47xx-1 -
kmod-usb2 - 2.6.23.1-brcm47xx-1 -
libgcc - 4.1.2-12 -
libphidget - 2.1.3-1 -
libpthread - 0.9.29-12 -
mtd - 6 -
ppp - 2.4.3-9 -
ppp-mod-pppoe - 2.4.3-9 -
uclibc - 0.9.29-12 -
udevtrigger - 106-1 -
wireless-tools - 29-2 -
Done.
root@OpenWrt:~#


I see posts in the OpenWRT forum that the Broadcom wireless is almost working with 2.6. I haven't tried fooling with that yet.
Top
 Profile  
 
sgm
 Post subject: Re: TagLost event
PostPosted: Sun Jan 27, 2008 9:34 pm 
Offline
Fresh meat

Joined: Fri Jan 25, 2008 5:34 pm
Posts: 3
I found that if I put the SLEEP line below in cphidgetrfid.c, it generates the TagLost events properly. For some reason, one of the conditions in the while () fails unless there's a very slight delay.

Code:
CThread_func_return_t tagTimerThreadFunction(CThread_func_arg_t userPtr)
{
        CPhidgetRFIDHandle phid = (CPhidgetRFIDHandle)userPtr;

        TESTPTR(phid);

        LOG(PHIDGET_LOG_INFO,"tagTimerThread running");

        SLEEP(1);  // Delay needed for OpenWrt on MIPS box

        while (CPhidget_statusFlagIsSet((CPhidgetHandle)phid, PHIDGET_ATTACHED_FLAG) && phid->tagTimerThread.thread_status == PTRUE)
        {
                if(phid->tagPresent != PFALSE)
                .
                .
Top
 Profile  
 
Mike_S
 Post subject:
PostPosted: Mon Jan 28, 2008 3:53 am 
Offline
Phidgetly

Joined: Wed Jan 23, 2008 2:07 pm
Posts: 15
Location: UK
sgm, thanks, you've done great work.
So you've got fully working rfid phidget, this is very nice, congratulations.
I wish I can reach this point some day :)
I'm going to buy another asus then. I cannot install kamikaze on the one I'm currently using because it's acting as a wireless router (obviously my girlfriend would kill me, she's already wondering why I play with this 'rotating thing' :wink: )
Debugging kernel USB drivers doesn't sound like fun to me but once I have servo working with 2.6 probably I will try to find out what's wrong with 2.4

thanks again sgm.
Top
 Profile  
 
Patrick
 Post subject:
PostPosted: Mon Jan 28, 2008 9:59 am 
Offline
Lead Developer
User avatar

Joined: Mon Jun 20, 2005 8:46 am
Posts: 2359
Location: Canada
It might be an issue with libusb (compiled into phidget21) on 2.4. If there is a libusb package specific to your kernel then you might have luck pulling the one that I include out of phidget21 and using the external library instead.

-Patrick
Top
 Profile Send private message  
 
Patrick
 Post subject:
PostPosted: Mon Jan 28, 2008 10:06 am 
Offline
Lead Developer
User avatar

Joined: Mon Jun 20, 2005 8:46 am
Posts: 2359
Location: Canada
Another issue might be if you have libhid installed - I see that libusb is unable to detect the kernel driver and so if something has claimed the Phidget, that would cause issues.

-Patrick
Top
 Profile Send private message  
 
Patrick
 Post subject:
PostPosted: Mon Jan 28, 2008 10:11 am 
Offline
Lead Developer
User avatar

Joined: Mon Jun 20, 2005 8:46 am
Posts: 2359
Location: Canada
SGM,

Thanks for pointing out this bug in the RFID. The correct fix is to add

Code:
phid->tagTimerThread.thread_status = PTRUE;

instead of the SLEEP. The problem was that I was setting this flag after starting the tread and the condition was failing before it got set. This will be fixed in the next release.

-Patrick
Top
 Profile Send private message  
 
Mike_S
 Post subject:
PostPosted: Mon Jan 28, 2008 4:37 pm 
Offline
Phidgetly

Joined: Wed Jan 23, 2008 2:07 pm
Posts: 15
Location: UK
Thanks for the suggestions Patrick.
I don't have libhid installed.
I'll try to link libphidgets with external libusb that is available via ipkg system on dd-wrt.
Actually I started adding lots of debugging messages to libusb (lines with "mdbg" prefix, the next number is PID).
For example, usb_control_msg now prints all requests.
One thing that crossed my mind was that maybe there is some problem with thread implementation in uclibc or how the libphidgets uses threads
Ideally I could modify my application to not to use threads (and libphidgets) and have very basic function to change servo position, without worrying about different callbacks etc.

This is a part of my debug log, with usb_control_msg returning -1
(broken pipe error)

Code:
mdbg (2908): Successfully opened /proc/bus/usb/001/001, fd 5
mdbg (2908): Successfully opened /proc/bus/usb/001/002, fd 5
mdbg (2908): Successfully opened /proc/bus/usb/002/002, fd 5
mdbg (2908): control_msg: fd 5, ret 4, type 128, req 6300, val 0, idx 255, size 1000, timeout 0
mdbg (2908): control_msg: fd 5, ret 12, type 128, req 6303, val 1033, idx 255, size 1000, timeout 0
USB error: could not get bound driver: No data available
mdbg (2908): Claimed interface 0
mdbg (2908): control_msg: fd 5, ret 32, type 129, req 62200, val 0, idx 255, size 500, timeout 268470296
mdbg (2908): control_msg: fd 5, ret 4, type 128, req 6300, val 0, idx 255, size 1000, timeout 8704
error sending control message: Broken pipe
mdbg (2908): control_msg: fd 5, ret -1, type 128, req 6304, val 1033, idx 255, size 1000, timeout 8704


There is a note in libusb sources related to threads
Code:
HACK: The use of urb.usercontext is a hack to get threaded applications
   * sort of working again. Threaded support is still not recommended, but
   * this should allow applications to work in the common cases.


so maybe it is worth to implement basic set_motor_position just to
confirm that the problem has nothing to do with the threads, uclibc etc.
Top
 Profile  
 
Mike_S
 Post subject:
PostPosted: Tue Jan 29, 2008 6:42 pm 
Offline
Phidgetly

Joined: Wed Jan 23, 2008 2:07 pm
Posts: 15
Location: UK
Patrick, can you please give me a hint what function directly
calls usb_control_msg to change the servo position?

Obviously
CSETINDEX(Servo,MotorPosition,double)
is calling FIRE(..)
which was set up ASGNFPTR, but I have some difficulties finding
actuall call to usb_control_msg. Somehow it ends up in CUSBSendPacket but I couldn't spot what's going on between FIRE and SendPacket.
Going through all these macros isn't very easy.

BTW, when I removed almost all calls to libphidget leaving only create, open and one call to setPosition it almost works. The servo goes to given position at full speed, about 70% of all runs of my test program.
The other 30% it does nothing. Maybe it's some kind of race.

I have found the reason why uhci driver is dumping debug messages and libusb returns error "broken pipe", when I call Phidget_open.
In cusblinux.c the function
int CUSBGetDeviceCapabilities is calling
usb_get_string_simple(udev, 4, (char *)phid->label, 11);
with index = 4 which return error and triggers usbi kernel driver debug messages.
If called with index=1 and index=2 it returns proper values:
Code:
servousb.c(31) usb_get_cap:1 get_string returned 13, Phidgets Inc.
servousb.c(31) usb_get_cap:2 get_string returned 12, PhidgetServo
Top
 Profile  
 
fitchett
 Post subject:
PostPosted: Tue Jan 29, 2008 9:06 pm 
Offline
Site Admin

Joined: Fri Dec 05, 2003 3:45 pm
Posts: 259
Location: Canada
In our own dabbling at Phidgets, we have run into issues with uclibc related to pthreads. I can't remember the exact explanation, but we switched to libc to get a full blown threading library. The memory is foggy, but uclibc had some of the pthread functions implemented, resulting in the threading calls going to two separate thread implementations.

Chester
Top
 Profile Send private message  
 
Patrick
 Post subject:
PostPosted: Wed Jan 30, 2008 11:23 am 
Offline
Lead Developer
User avatar

Joined: Mon Jun 20, 2005 8:46 am
Posts: 2359
Location: Canada
CSETINDEX calls SENDPACKETINDEXED which is a macro that calls CMAKEPACKETINDEXED to build the packet buffer, and then queues it with CSENDPACKET_BUF, which signals the write thread.

The write thread (running WriteThreadFunction in cthread.c) picks up the signal and calls CPhidget_write (defined in cphidget.c) which takes the queued up packet and send it out to USB by calling CUSBSendPacket.

If you want to try and send out packets yourself, look at CMAKEPACKETINDEXED in cphidgetservo.c, to build the packet and CUSBSendPacket in cusblinux.c to send it.

Hope that helps.

-Patrick
Top
 Profile Send private message  
 
Mike_S
 Post subject:
PostPosted: Wed Jan 30, 2008 1:42 pm 
Offline
Phidgetly

Joined: Wed Jan 23, 2008 2:07 pm
Posts: 15
Location: UK
Patrick, many thanks for the information.
It was not quite easy to get through all those macros, but
with the 'gcc -E' I made it.

Finally I have the servo working properly, I can rotate it smoothly all 180 degrees without any problems.
Fortunately it is not the hardware problem nor kernel driver issue.
Definitely it's a thread problem, I'm not sure where it is exactly, maybe
I'll spend some time finding the main cause.

Probably there are not too many people playing with phidgets on dd-wrt or openwrt but to satisfy google here is the program that works
on dd-wrt v23 sp2, kernel 2.4.34-pre2, uclibc 0.9.28, tested
on asus wl500g premium.

It's using libusb 0.1.12 only.
It's assuming that the motor is connected to port 0.
Get libusb sources, and compile the program with following Makefile (all files except servo.c are from libusb):
Code:
OBJECTS=servo.o descriptors.o error.o linux.o usb.o
CFLAGS=-g -Wall

all: $(OBJECTS)
        $(CC) -o servo $^ $(CFLAGS)

clean:
        rm -f $(OBJECTS)


servo.c
Code:
#include <stdio.h>
#include <strings.h>
#include "usb.h"

#define USB_VENDOR      0x6C2
#define USB_PRODUCT     0x38
#define SERVO_MINPOS    -23
#define SERVO_MAXPOS    232

static int pdd_iid = 0;

static int setpos(struct usb_dev_handle *udev, double pos)
{
        char buf[8];
        int ret, pulse = (int)(pos * 10.6 + 243.8);

        bzero(buf, sizeof buf);

        buf[0] = pulse & 0xFF;
        buf[1] = pulse >> 8;
        ret = usb_control_msg(udev, USB_ENDPOINT_OUT |     USB_TYPE_CLASS | USB_RECIP_INTERFACE,
                        USB_REQ_SET_CONFIGURATION, 0x0200, pdd_iid,
                        (char *) buf, 6, 500);

        return ret;
}

struct usb_bus *bus;
struct usb_device *dev;
usb_dev_handle *udev;

int main(int argc, char **argv)
{
        double pos;

        if (argc < 2) {
                fprintf(stderr, "Need arg: new_pos (float)\n");
                exit(1);
        }
        pos = atol(argv[1]);
        if (pos < SERVO_MINPOS || pos > SERVO_MAXPOS) {
                fprintf(stderr, "Invalid range, servo min pos: %d, max pos: %d\n",
                        SERVO_MINPOS, SERVO_MAXPOS);
                exit(1);
        }
        usb_init();
        usb_find_busses();
        usb_find_devices();

        for (bus = usb_busses; bus; bus = bus->next) {
                for (dev = bus->devices; dev; dev = dev->next) {
                        if (dev->descriptor.idVendor != USB_VENDOR ||
                                dev->descriptor.idProduct != USB_PRODUCT)
                                        continue;
                        goto FOUND;
                }
        }

        fprintf(stderr, "Phidget device has not been found.\n");
        exit(1);
FOUND:
        udev = usb_open(dev);
        if (!udev) {
                fprintf(stderr, "Cannot open usb device.\n");
                exit(1);
        }
        setpos(udev, pos);
        return 0;
}


It's very simple, makes many assumptions, but it is working and
it's good starting point.
Put setpos() inside a loop with a usleep(20000) and the movement
will be slower and smoother.
Of course $(CC) should point to mipsel-linux-uclibc-gcc to cross compile etc. but this is a different story.
Actually this is a stripped version of servo.c, I've got simple functions to get capabilities, driver description etc. but I don't want to spam too much.

Thank you for your help and all suggestions.
I have to improve my small lib but I'm glad I can progress
with my main application.
Top
 Profile  
 
jolouis
 Post subject:
PostPosted: Fri May 16, 2008 5:13 pm 
Offline
Fresh meat

Joined: Thu May 15, 2008 9:21 pm
Posts: 1
Mike_S, if you're still around I'd love to see any information you're willing to share about getting the phidgets libs onto OpenWRT/dd-wrt. I've been fiddling for the last two days with getting them to compile, and after basically re-writing half of the Makefiles I managed to get both the core library and the examples to compile under the OpenWRT Kamikaze SVN buildroot, but when I go to run the example it just segfaults on me...

Thanks!
-Rob
Top
 Profile  
 
fitchett
 Post subject:
PostPosted: Fri May 16, 2008 6:03 pm 
Offline
Site Admin

Joined: Fri Dec 05, 2003 3:45 pm
Posts: 259
Location: Canada
You may be having problems with OpenWRT if it uses uclibc. Uclibc has some issues with pthreads.

Chester
Top
 Profile Send private message  
 
Mike_S
 Post subject:
PostPosted: Sat May 17, 2008 2:35 pm 
Offline
Phidgetly

Joined: Wed Jan 23, 2008 2:07 pm
Posts: 15
Location: UK
Hi again,

Fortunately I'm receiving email notifications about new posts so you could say I'm still around :)
I have got all software working properly, here is the page with some photos, no interesting content yet, I'm just creating it, but I'm going to describe all my problems and solutions there, along with a software I wrote that is currently running to control web camera:

DYI tilt/pan cam

I have servo Phidget with 2 servos connected to it, some metal brackets and a web camera on top of it.
I'm not using Phidget library, I wrote a daemon server, linked with libusb directly, that receives messages from the applet embedded on a web page and controls servos movement. Using libusb is very simple and it was much simpler for me than debugging threading problems.
As you see on the photo, there are 4 arrow icons on the web page that you can control pan and tilt with.
It is working pretty well although I'm going to buy better web cam (probably Philips camera that better supports different light conditions) and I'm going to start using palantir server to achieve higher frame rate (currently the html frame that contains jpg refreshes every second).
I have got also simple program to control servos from the command line, this is pretty much the same program that I listed in my previous post.
jolouis, if you want to use servos connected to your Kamikaze box then I think it is much easier to use libusb directly. I think I would have spent much more time on debugging phidgets library/uclibc thread issues than writing my software to control servos.
Actually I had no problems with compiling libphidgets for mips using DD-WRT build root. If I remember correctly I just changed gcc to $(CC) in Makefiles and it worked fine. I'm using DD-WRT build root:
DD-WRT tool chain
jolouis, what do you want to use libphidgets for?
Is it for servo motors?

Cheers,
Mike
Top
 Profile  
 
jeffrafter
PostPosted: Wed Dec 30, 2009 8:19 am 
Offline
Phidgetsian

Joined: Wed Dec 30, 2009 8:13 am
Posts: 5
I realize this thread is pretty old, but I am trying to get the phidget servo controller working on openwrt as well. I have tried the program that Mike_S included and just get:

Phidget device has not been found.

I am guessing I still have a difference in build/packages installed and was wondering if anyone has got this working (or if Mike is _still_ around :))

Thanks,
Jeff
Top
 Profile Send private message  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 2 of 3
  [ 38 posts ]  Go to page Previous  1, 2, 3  Next

Board index » Programming - General and OS » Linux

All times are UTC - 7 hours [ DST ]

Who is online

Users browsing this forum: No registered users and 0 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
| Policies | Licenses | Projects | Facebook logo |

All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest (c) 2012 by Phidgets, Inc.
UPS, the UPS brand mark, and the Color Brown are trademarks of United Parcel Service of America, Inc. All Rights Reserved.