I-Appliance BBS The Official Source for Internet Appliance Upgrades and Mods BBS Main List | Sign In | Sign Up | Search | Help | Linux-Hacker.net Reply to Thread | Printer |

Home / I-Appliance BBS General / NEWS, Breaking NEWS xanboo

xanboo (modified 0 times) jsmmd Profile "As the world's leading provider of Internet-enabled devices, Xanboo offers a complete solution for services revolving around the ability to access and control any enabled device, anytime, from anywhere with Internet access." http://www.xanboo.com I have a bunch of the xanboo modules. Seems like they are x-10 compatible. The idea is neat. Pay a montly fee for service, and the software will notify you if the Xanboo Windows connected computer triggers an event. Anyone here got this stuff besides me? http://search.ebay.com/xanboo_W0QQsokeywordredirectZ1QQfromZR8 08-27-2004 14:43:57

RE:xanboo (modified 0 times) 02U2 Profile They had been selling that xanboo stuff at comp-usa. I don't know if they still do. I remember seeing it about a year ago. 08-27-2004 20:38:51

RE:xanboo (modified 0 times) jsmmd Profile Yup, Codeman said Lowes & Compusa have the Xanboo stuff, maybe at deep discounts. extreme tech article hummm... Xanboo Admin(s). seem to be up to no good. "Hacker alias, Monkey (Name Withheld, Unix Administrator at Xanboo) hacked into my secure login box on July 10th." 08-27-2004 21:48:13

RE:xanboo (modified 0 times) 02U2 Profile I've been watching thier trash, They usually clearance certain stuff that does not sell well to a certain price then after that SMASH whatever is left and out it goes....to the landfill. It's kinda funny how they smash a lot of thier stuff sometimes. They may do the outer casing on some large quantity stuff and on the next units they smash the plug or connector or cut the cable off leaving the original outer casings intact. It's fun making usable units out of their stupidity. 08-28-2004 16:22:42

Using it without Xanboo Service? (modified 0 times) TivoTechie Profile Has anybody done any work on using Xanboo devices without paying for Xanboo service? I've done some digging and can't find anything about using it on a linux platform... I see the stuff on sale all the time... but can't find any pictures, or any evidence that the hardware could be reused without xanboo... does anybody have... 1) A linux USB driver for the controler 2) Pictures of the actual devices and thier insides 3) any experince using them for anything else? (Like hooking the camera up directly to something, or using with an alarm system) 08-30-2004 11:06:13

RE:xanboo (modified 0 times) jsmmd Profile Well, so far I read from the windows drivers the following: ; modified for events without video ; with Core names ; 6.23.00 ; NUVision.inf ; ; Installation inf for the Nogatech USBVision based devices. blah..blah.. ;This driver INF has being generated for Corecam to use NT1004 EVB with NTSC analog ;(composite) video source through NT1004 EVB on-board video decoder. ;The setup has being tuned to support CCIR656 with synchronization pulses video format ;in the best way. more blah.. Yahoo! lead me to this http://sourceforge.net/projects/usbvision "Development of a device driver for USBVision (NT1003/NT1004) chipset" (Linux Drivers Foundry) I can't tell what type of chip is in it, cause there's a hard candy shell (ok, not candy, more like plastic), on top of main chip. I'll try to take some pics. Anyone that's a windows hacker/programmer could most likely make easy work of the whole system. There's plenty of well named OCX's and DLL's in the install folder. (e.g. XanControl.ocx, XanSensors.OCX), and 1 EXE. PS - Netmeeting sees the camera (camera 1) just fine. 08-30-2004 16:49:42

RE:xanboo (modified 0 times) jsmmd Profile Some pics: http://www.linux-hacker.net/~jsmmd/devices/xanboo/pictures/inside_back.jpg http://www.linux-hacker.net/~jsmmd/devices/xanboo/pictures/inside_top.jpg http://www.linux-hacker.net/~jsmmd/devices/xanboo/pictures/inside_top_b.jpg 09-02-2004 13:57:15

RE:xanboo (modified 0 times) jsmmd Profile Chips: U3 ----- Philips SAA7113H CZ6907 HPD00271 U2 - pic ------ Microchip PIC16C57-HS/P 0020JQJ U7 ------ NT1004 (thanks to fireether: 01-27-2005) U1 ------ OKI Japan M7716 017232C U9 ------ Philips? HEF4052BT D0599me Hnn0009 6 U6 ------ GLT GLT440L16-35TC 0012 6685G U3 ------ Microchip PIC16C54C 04/P 0022JA2 09-06-2004 12:54:56

RE:xanboo (modified 0 times) zooloo Profile The usbvision drivers will work w/ these cameras, there may be some slight patches needed (I worked with a couple of these a while back) Anyway there are also some mods to get access to the motion detector in the camera as well as switching inputs. If anyones interested i can dig up the driver patches i did a while ago. -zooloo 09-11-2004 22:29:03

RE:xanboo (modified 0 times) jsmmd Profile cool. please do. 09-11-2004 23:50:31

RE:xanboo (modified 0 times) scooter Profile Yeah, I'll second that. The Xanboo software really sucks, 3 years old. Can't believe it's still a business. Someone else came out with "replacement" software but it wasn't cheap. They wanted like $130. Seems they've abandoned selling it. 09-30-2004 14:07:38

RE:xanboo (modified 0 times) Anasazi Profile Any news on this? I'm kinda interested to get this silly thing off my Windoze PC and onto my Linux box where it belongs :) On another note, looks like they're branding it for uncle Moto and Shell as well: http://www.motorola.com/homemonitoring http://www.shellhomegenie.com 10-18-2004 19:06:58

RE:xanboo (modified 0 times) TivoTechie Profile The usbvision drivers will work w/ these cameras, there may be some slight patches needed (I worked with a couple of these a while back) Anyway there are also some mods to get access to the motion detector in the camera as well as switching inputs. If anyones interested i can dig up the driver patches i did a while ago. -zooloo any luck digging up the driver patches/drivers? 12-01-2004 08:04:05

RE:xanboo (modified 0 times) fireether Profile I've done alot of research, and I've made a circuit diagram from the reciever. My theory is that since (please refer to the above chips, I'm refering to chips on the board) U7 is covered, and it has a video switch (U3), and since somebody reported that the linux USB driver for SAA7113 works with it; that the sensor information is encoded into the picture frame. My original theory was that U7 (which xanboo took pains to make sure we cant identify) was the USB controller.. And since they use microchip for their microcontrollers, I wouldnt be surpraised if U7 was also a microchip microcontroller. However, for starters, it has too many pins. I've used PIC18F452, which has 40 pins, and U7 has 100 pins. Plus U7 has RAM. So.. 1.) USB is shared between the SAA7113 and U7. Or.. 2.) U7 is not connected to the USB, but takes the picture data and then encodes data from sensors into the frames and sends it. I ran an USB sniffer, and I found that theres a very high rate of data transmission, even without a camera attached. The log file was about 21 MB after 5-10 seconds. If it was just sending "camera not connected" and all the data for each sensors, it would not be nearly 2MB/sec data transmission rate. All of this is theorical so far. I got version 0.9.8 of usbvision and then since they didnt recognize xanboo by default (vendor id: 0x0a6f product id: 0x0400), I edited usbvision and added in the entries for those, then recompiled. Only problem now is that usbvision crashes, I'm checking into why its crashing after detecting xanboo. I'll report back if I find anything further. The part that I've focused the most on is the reciever (the board) because thats more important to me since I'm buying transmitters and then embedding them into security devices, and will use the reciever with my own microcontroller/computer to implement a home security solution. To me, the camera feature of xanboo is cool but can be done by other devices that already have linux drivers developed for them. 01-26-2005 23:25:30

RE:xanboo (modified 0 times) fireether Profile An update. First, i want to refer to an earlier message, about X10 and xanboo. The main xanboo device is a reciever, and it DOES not put out any transmitting signals, and it does NOT produce signals on the powerline, which X10 does. X10 radio devices (RF devices) -could- be used to control xanboo, but xanboo cannot control X10 devices without an addon, such as something that would plug into the EXP port, or another upgrade. This is based on the following facts: -X10 is mostly powerline, except the RF transmitter and wall-plug-in reciever, of which the transmitter may be able to be interfaced with xanboo if they both use the same frequency and encoding.. -Xanboo doesnt have the ability to send signals through the home wiring, it can only recieve signals via RF (the main unit). However the transmitters can transmit signals, but why would a transmitter be interface to an X10 reciever, and not the xanboo device? The xanboo software could be modified to also use X10 if a X10 control module was plugged into the PC (i.e. firecracker). Just wanted to set the record straight. Now to the updates. I've traced the USB connections, and D+ (white wire) goes to Pin 100 on U7, while D- (green wire) goes to pin 99 on U7. Neither pin goes to the SAA7113 chip, and the SAA7113 chip doesnt have USB capability as far as I know. However the SAA7113 outputs its digital video signal to U7, and U7 connects to the USB. Therefore the key to getting xanboo to work with linux or any other custom software is to figure out U7. In addition to this, U7 is connected to U2 which suspeciously looks like an EEPROM, so I decided to trace some of the connections between U7 and U2. I found out that U7 pin 94 connects to a transistor which seems to switch power on and off to U2, and also connects to U1, pin 25. U1 came up as "Single rail linear CODEC". U2 is connected to U7 (so far) by 4 connections, U2 pin 6, 7, 8, and 9. However, 6 and 9 are connected together, and are connected to U7 pin 100, which is also USB D+. U7 pin 99 which is USB D-, connects to U2 pin 8. So it looks like, if U2 is an eeprom or other rom, that its powered on upon bootup, and the processor (U7) executes code from it, and then powers off U2 in order to use the USB port. Another update: Just brought up some EPROM/EEPROM diagrams for 27C64, 27C128, 27C256, also 28-64, 28-128, 28-256.. All have VCC and GND in the same places, and traced ground.. Ground goes through 2 resistors, through an inductor then to U7 pin 42.. 35, and 36.. SO its possible that the chip that looks like an eeprom/rom isnt really one.. However there is a RAM connected to U7, so therefore U7 is a processor of some kind.. If U2 is a ROM, its connected in a wierd way. Can somebody attempt to read the chip and see if its a ROM chip? I believe its an EEPROM. 01-27-2005 05:17:37

RE:xanboo (modified 0 times) fireether Profile Correction, Its not a ROM or EPROM. Its a PIC16C57-HS/P. I had to scrape all the sticky stuff off the top of the chip to see the fine print, which I didnt even notice until I scraped the stuff off. The chip's voltage range 2.5-6.25. On mine, 3.272v goes to the PIC16C57 and to the reciever. It has 2Kx12 words EPROM Program memory, 72 bytes RAM data memory, 20 I/O pins, and comes in 28-pin DIP. RB0 connects to pin 10 on U1 (HEF4052BT), and RB1 connects to pin 9 on U1. RA0 connects through a capacitor, then splits. One way goes to another capacitor to USB D+, and pin 100 on U7 whil the other way gos through a resistor to Pin91, through a capacitor to ground, and through another capacitor to RA3. RA1 connects through a capaictor and resistor to U7 pin 89, and connects through 2 capacitors to U7 pin 99, which is USB D-. RA2 connects through a capacitor and a resistor to U7 pin 95, and connects through 2 capacitors to ground. In other words, in plain english, the USB signals goes to both U7 and the PIC16C57. I'm starting to wonder what U7 really is. I know for sure that the PIC does not interface with the RAM. The RAM is interfaced with U7. And why pick a PIC that is removable and not surface mounted? Maybe because its a programmable chip? Therefore, if U7 is not programmable, would that be the reason why its surface mounted? My guess is that the PIC may help U7 to boot up.. Or U7 could be a special kind of processor that requires RAM and does what its told.. I.e. putting characters in a data stream (i.e. video stream) and sending it back to the computer? For sure USB isnt connected to the SAA7113. And the PIC doesnt have native support for USB unless its programmed to understand the USB and to act on it? Too many questions and not enough answers, hopefully somebody can figure out what U7 could be from all the information provided. I'll start figuring out how the reciever works, and will post on that if people are interested. 01-27-2005 05:48:32

RE:xanboo (modified 0 times) fireether Profile Sorry to post so many times, but apparently I cant modify my own entry. :-P This's my last post for a while. Another thing is that when the LED is "red", i.e. its not connected to xanboo - the PIC16C57 is powered down to 0.664v, along with the transmitter. So therefore the PIC cant help U7 to "boot up". However, the PIC fully interfaces with the reciever (and the reciever PIC), so thus its possible that the PIC16C57 is responsible for taking the data and inserting it into the USB stream. The reciever gives an output and doesnt accept an input, so either the PIC16C57 listens to the USB stream and then has U7 respond back or it uses U7 to send a video stream (or U7 does it itself) and then PIC16C57 inserts the sensor data at the end.. This makes more sense because Xanboo uses a low-level driver which could pick up the added data. Plus when the xanboo system is plugged into a windows or a linux computer, it comes up as 1 interface, which is the video interface. In reality its probably 2.. The video, which can be used by other drivers, and the added data. This way windows doesnt activate the reciever or PIC16C57 and then accidently gets confused by more data than expected coming in.. So to prove this theory: 1.) Find a way to activate the device, i.e. make the LED go green. 2.) Monitor the USB input, and at the same time, have a wireless sensor switch on and off, or send the "test" signal (when you press the button on it) 3.) Notice if theres any changing data.. Without a video camera in, the frame data should be blank or noise.. But the change in the sensor data should be clear. Then if theory is right.. 4.) Write a USB driver that will work with this. I.e. expand on the working driver, and add capability for the data. Or for people who dont want video, make a driver or program that will activate the device and discard the video data. 01-27-2005 06:25:00

RE:xanboo (modified 0 times) jsmmd Profile fireether, wow, snaps to you chap. I can't write drivers, heck, I can't really do too much in linux. If you can email me some details I can install Fedora, or whatever, and try to help out. As for your items above with the help of a OCX decompiler and some other monitoring software it may be possible to determine this on a windows machine and then translate this into Linux. Just a thought. jsmmd / MethodicJon 01-27-2005 13:38:31

RE:xanboo (modified 0 times) fireether Profile =-) I somehow blew out the part in the board that controls power.. Not sure what happened. As of now it will not power up from USB, but it powers up from the 12v just fine.. But even when its powered up, it does not seem to work with the USB on my computer any more. In addition, I rigged up a PIC16C54 and 16C57 reader, and I read in both the 54C and 57 chips.. I got about 1/4 of the code from the 54, and the rest was blank, yet the code isnt code protected.. So I'm not sure why I got that. As for the 57, it showed up as all blank. I quadriple checked the connections, same thing, and the 57 is supposely a one-time-programable eprom.. Perhaps I accidently overwrote the whole code on the 57? That would explain why the device doesnt seem to "power up" when connected to the USB. So this gives me a theory that the 57 controls more of the USB than was originally thought. I'm getting a new xanboo from ebay, and then I'll do the following: -Take out the 57, and see if it still works with the xanboo software via USB, and if windows/linux detects it. If not, will reinsert the 57, and then if windows/linux can detect it, then the 57 is coded to act as a USB 1.0 chip.. -Take out the 57, and read it, see if my probing around with it caused the original 57 to not give all the code. Same with the 54. -Sniff the protocol between the 57 and 54. Currently I'm more interested in the wireless part of the xanboo than I am in the video input part. But since I need to know how the 57/54 works for the wireless, and since the 57 is also used for USB, I'll post my findings here. Just keep in mind that I'm more focused on learning how the 54 reports activity from wireless sensors to the 57. I still have no idea what the mysterious chip (U7) is, I still theorize that its a processor of some kind because any kind of processors would need RAM (either internal or external). Im also curious to why its ID is "hidden", while the PIC's are not hidden from the public. Any other engineers, people out there who have the ability to read in the contents of PIC's and have an xanboo system - do you want to read in the contents and then comment on them? I may never release any code from the PIC's because it would most likely result in giving away xanboo's intellectual property, but I would comment on how it works without giving away any code. 01-31-2005 11:22:51

RE:xanboo (modified 0 times) fireether Profile In reply to jsmod: "fireether, wow, snaps to you chap. I can't write drivers, heck, I can't really do too much in linux. If you can email me some details I can install Fedora, or whatever, and try to help out. As for your items above with the help of a OCX decompiler and some other monitoring software it may be possible to determine this on a windows machine and then translate this into Linux. Just a thought." I dont write drivers at all in linux, but I'm willing to give it a try as long it doesnt take up too much time.. Since I have classes and so forth. I could use a OCX decompiler, and I have used monitoring software.. That resulted in a huge log file that I have to parse through, and I dont have experience with USB's protocol yet.. That may change because I'm going to order some PIC's with USB support for a different product. After looking through the log file and trying to decode the USB stuff, I gave up and instead turned to what I do best - hardware reverse-engineering. It doesnt help that the device and the xanboo software are "noisy" talkers.. Think of appletalk in the past for an example. They keep sending each other packets even when theres no video connected, and theres really no way for me to easily tell what the packets contain - i.e. is it sending status? video data from the 4 video ports? sensor data? is this packet video data and the next sensor data? I may find more answers once I figure out the PIC16C57/54, and answer part of the question. Lets see what happens. 01-31-2005 11:27:32

RE:xanboo (modified 0 times) fireether Profile I was looking back up through the threads, and yes, I can confirm that U7 is a NT1004 chip. I have found that USB goes to pin 100 and 99, which corresponds with the datasheet that I aquired (through a google search) of the chip. The chip supports video and audio, and does it through USB. However, the USB vendor id: 0x0a6f product id: 0x0400 wasnt recognized by the USBVISION driver.. So I suspect that it was changed so that way only the xanboo driver will support it.. And thus netmeeting and others can use the device through the xanboo driver. From the documentation: "End-Point #0: This is the descriptors and configuration end-point End-Point #1: This is the NT1004 register bank; the host computer uses these registers to control the NT1004 and Camera End-Point #2: This End-Point produces and sends the digital video data to the host computer. End-Point #3: This end-point sends the input digital audio data to the host computer. End-Point #4: This end-point sends the external bulk data input to the host computer." Notice end-point #4, its possible the sensor information was send through there.. Then why was the 16C57 connected to the same pins as the USB? In addition, the NT1004 is a processor, and thus requires RAM, which explains the on-board RAM. External serial EEPROM is optional, and if its included - "it allows the manufactor to define new configurations." U9 is not the serial eeprom, its a "Dual 4-channel analogue multiplexer/demultiplexer". However, U8 is a serial eeprom, 24LC16B, made by microchip. A probe test confirmed that the serial data out from the eeprom is connected to the serial data input of the NT1004. In addition, the vendor/product ID can be set by setting certain pins of the NT1004 on/off. So I am now 99% certain that xanboo uses NT1004, and that U7 is a NT1004, or a NT1004 compatible chip. Thus, USBVision for linux should work with it. And apparently the digital data about sensors, etc is sent through the usb from the PIC16C57.. But I'm not 100% sure about this - I will know more when I get the code for the PIC16C57. See if this works for you.. Apparently the driver interfaces with NT1004 and then talks to the SAA7113 or SAA7114 through the NT1004 chip.. When I did this, the module itself crashed after it detected my device - I had a brain fart and set the interface to 1, it may have to be -1. See if you guys can get anywhere with this. 1.) Download USB vision from the website, http://sourceforge.net/projects/usbvision - Version 0.98 or newer prefered. 2.) Untar/gzip it.. I.e. tar -zxvf .... 3.) Change into the usbvision dir. 4.) Change to the SRC dir. 5.) Edit usbvision.h 6.) Under usbvision_device_data[] add to the end: {0x0A6F, 0x0400, -1, CODEC_SAA7113, 4, VIDEO_MODE_NTSC, 1, 0, 0, 0, -1, -1, -1, -1, -1, "Xanboo"} Which does this: idVendor = 0x0A6F, idProduct = 0x0400, Interface = -1, Codec=Codec_SAA7113, VideoChannels = 4, VideoNorm = Video_Mode_NTSC, Audio Channels = 1, (remember its multiplexed), Radio = 0, Tuner = 0, TunerType = 0, Vin_Reg1 = -1, Vin_Reg2 = -1, X_Offset = -1, Y_Offset = -1, Dvi_yuv = -1, ModelString= "Xanboo" Under usb_device_id usbvision_table, add to the end: { USB_DEVICE(0x0A6F, 0x0400) }, /* Xanboo */ Then save it, compile the driver, and see if it works. 01-31-2005 12:12:39

RE:xanboo (modified 0 times) fireether Profile Just got my new xanboo, made the changes that I talked about in my last post, and success. Xanboo officially works for linux (video only) with the changes made. I'm not sure if I'll have time to make the sensors work in linux, because of college. Is there anybody else who can do it? I would start with the data stream (remember that the chip supports a data channel) - may need to modify the usbvision driver so that data stream can be outputted somewhere (log?) and then can find out if thats really the data or not. 02-14-2005 15:26:22

RE:xanboo (modified 0 times) fireether Profile When looking at the video data, theres a red line to the right of the picture, not sure why its there. It flickers blue once a while, but mostly stays red.. Its like this: (an example) On the X axis.. ~200 pixels of video data, ~20 pixels of black, ~20 pixels of red line. The redline could be used to "communicate" data to the computer.. Its possible that its value can be changed slightly (i.e. from 255 to 254 then to 255), but I'm not sure if this is waht happening. So far, to me, the data seems to be going through the bulk data interface, which is an endpoint in the NT1004 chip. The NT1004 chip communicates with the SAA7113H through a I2C interface. USB Vision project supports this, and thats why with USB vision, you can see the video input from the camera in real time. However, USB vision doesnt support audio from the NT1004 yet. The author has made some attempts into doing audio. I've used his beta audio software, which has erros for me, I will work on it later on. The USBVision project supports radio devices, which would communicate through the I2C interface to the NT1004, and so forth. However I know that the audio isnt being streamed through the audio port (yet) for the USBVision project because in order to do that, the AUDIO_CONT register would have to be enabled, and by default its disabled. The AUDIO_CONT register also controls if the bulk data is streamed through it. To me, it seems that the data from the sensors is either being streamed into the picture data or is being streamed into the audio endpoint. Remember, I cant eliminate the picture data as a possible sensor data source yet because of the red bar in it. Using XAWTV and USBVision from CVS - 2/15/2005.. TV Norm: Auto. Also works with NTSC. Video Source: Composite 1 gives 1st camera output. S-video doesnt give any output from any camera inputs. Both show a red line to the right of the picture frame. Audio Mode: Mono Capture: grabdisplay. Overlay doesnt work, but thats because of the way my system is setup. Using Gnomemeetign and USBVision from CVS - 2/15/2005.. In video devices (in preferences): Video Plugin: v4l Input device: USBVision USB Video Size: Large (small doesnt work well for some reason).. Large is CIF 352x288, small is QCIF 176x144. Format: Auto Gnomemeeting detects 4 channels (channel 0 through 3). All 4 show the red bar. When camera is plugged into cam1, and channel is set to zero, it shows video from the camera. But when channel is changed to 1, it doesnt show video from cam2. Channel 2 and 3 show a line pattern, but gnomemeeting shows video from channel 0 on channel 3, and the line pattern on channel 2. All the channels that have the redline, lose the redline when the size is changed to small. However, when the size is small, the video looks messed up. It looks normal with a large size. I downloaded and ran Palantir, which allows streaming of audio and video over the LAN/Internet. It has a server and client part. The output of the server is: [main] -- palantir 2.5.5 starting -- [main] Definitions for 0 devices found [main] No serial port specified [main] No named pipe specified [video] Card: USBVision USB Video (/dev/video0) [video] Capabilities: 41 (capture overlay clipping) [video] Size: (64x48)-(320x240) [video] Channel no. 0 ('Composite 1') tuners: 0, flags: 2, type: 2, norm: 3 [video] Channel no. 1 ('S-Video') tuners: 0, flags: 2, type: 2, norm: 3 [video] Channel no. 2 ('S-Video') tuners: 0, flags: 2, type: 2, norm: 3 [video] Channel no. 3 ('S-Video') tuners: 0, flags: 2, type: 2, norm: 3 [video] Unmuted audio input 0 [video] depth: 24 palette: 4 etc. Connecting from the client to the server, gave me the same video that I got in gnomemeeting and xawtv.. Except that the FPS was much better. My laptop that I'm testing USBVision on is a P3 733MHz, and doesnt have a very good video card. So naturally video applications on the laptop will be a bit slow. Also the color via palantir seems much better. If USBVision can be modified to support audio from the NT1004, maybe Palantir can be modified (with permission) so that it can be used for Xanboo remote monitoring. The fps using palantir is ~16.50 fps on average. The red line is still there. Trying 300x200, the video is messed up, same with other modes. 320x240 works. I took a screen shot of it. I set the window so it will not stretch the video to the window, so I can say for sure that the video being outputted by the NT1004 is smaller than 320x240 but its enlarged to 320x240. For example: When I reduced y to 100 (320x100), the y axis of the video window reduced. However, the X stayed the same, and I could still see the picture. However if I reduced the x axis (for example, 160x170) the video always got messed up. Therefore, the x-axis is fixed to 320, while the y axis can be resized. So the red line could be a way for the xanboo client to know where to "clip" the screen. The picture is in this folder. http://rocnoah.mine.nu/noah/xanboo/ Since I'm doing more research into this, I may start putting documents in that location instead of here because this topic is in "News, Breaking news" and I'm not sure if the administrators/moderators approve of me constantly updating this topic as I find more information. I'd rather not have my access removed. I'll also save a copy of this thread into that location because alot of my notes are on here. I looked into usbvision.c, and it seems that usbvision is the reason why xawtv and other programs print out "composite" and "s-video". Remember that USBVision is mainly for tuners, capture devices and some other devices like that (as far as i know) and wasnt made for Xanboo and does not include support for xanboo natively. I'm working on that. I may get in touch with the developers of USBVision about myself writing code for it that will support Xanboo.. However this will be my first attempt at programming a driver, and thats one reason why I'd rather work with USBVision than to start my own driver since I'd have to program it from scratch. However, there are some specifics in Xanboo that are not found elsewhere.. Such as the possible usage of the audio endpoint for bulk data, which would require coding the driver in a way that may end up making a specialize device (/dev/xanboo?) just to output the audio. And thats not including the camera select chip. In addition to this, theres a chip that supports switching between multiple video sources.. This is connected to the SAA7113, and would explain why there are only 1 workable video source in the programs that I have tested so far. I'm not sure why. Last but not least, the red line could be used for sync. In other words, when the picture frame is synced right, the red line will show up right. If its synced wrong (i.e. X isnt the right value), the red line will not show up. Last but not least, jsmmd, U7 is NT1004 not PIC16C57-HS/P. 02-18-2005 11:29:25

RE:xanboo (modified 0 times) USBVisionGuy Profile The usbvision driver for linux should handle this device properly. The only thing which is missing is the 4 inputs. It should not be too hard to code that part into the driver. The driver was coded for USB Video TV tuners in mind. Since most of the devices are TV Tuners. But the device requirements can be added to the driver. Since this device is using the NT1004 and SAA7113, there will be some white interference with the video output. We can turn that off, but it will reduce the fps to around 18. I have added this device to the usbvision cvs, and will work with the guy that notified myself about this activity. The USBVision driver is completely open source. I have added a lot of patches which people have submitted. This driver would not be at the state it is today if people did not get involved in the testing. Keep testing guys... 02-20-2005 14:00:14

RE:xanboo - Patches to USBVision Linux Driver for four inputs. (modified 0 times) USBVisionGuy Profile Here is a patch to add three video inputs. Just change the 3 to 4, with the additional code for the fourth video input. It should work fine. This is the patch for usbvision.h: ===================================== --- usbvision.h 2004-11-13 12:38:20.000000000 +0200 +++ ../../usbvision/src/usbvision.h 2005-01-06 14:15:09.000000000 +0200 @@ -324,7 +324,7 @@ /*{}, CUSTOM USBVISION DEVICE do not move, must be first*/ {0x050D, 0x0208, 0, CODEC_SAA7113, 2, VIDEO_MODE_PAL, 1, 0, 0, 0, -1, -1, 0, 3, 7, "Belkin USBV iew II"}, {0x0573, 0x0003, -1, CODEC_SAA7111, 2, VIDEO_MODE_NTSC, 1, 0, 0, 0, -1, -1, -1, -1, -1, "USBGear USB G-V1 resp. HAMA USB"}, - {0x0573, 0x0400, -1, CODEC_SAA7113, 2, VIDEO_MODE_NTSC, 0, 0, 0, 0, -1, -1, 0, 3, 7, "D-Link V100 "}, + {0x0573, 0x0400, -1, CODEC_SAA7113, 4, VIDEO_MODE_NTSC, 0, 0, 1, 0, -1, -1, 0, 3, 7, "4-input USB video suveillance"}, {0x0573, 0x2000, -1, CODEC_SAA7111, 2, VIDEO_MODE_NTSC, 1, 0, 0, 0, -1, -1, -1, -1, -1, "X10 USB Cam era"}, {0x0573, 0x2d01, -1, CODEC_SAA7113, 2, VIDEO_MODE_NTSC, 0, 0, 0, 0, -1, -1, 0, 3, 7, "Hauppauge U SB-Live Model 600"}, {0x0573, 0x2101, -1, CODEC_SAA7113, 2, VIDEO_MODE_PAL, 2, 0, 0, 0, -1, -1, 0, 3, 7, "Zoran Co. P MD (Nogatech) AV-grabber Manhattan"}, ===================================== and this one is for usbvision.c ===================================== --- usbvision.c 2004-11-14 03:02:07.000000000 +0200 +++ ../../usbvision/src/usbvision.c 2005-01-06 14:32:20.000000000 +0200 @@ -386,8 +386,8 @@ MODULE_AUTHOR(DRIVER_AUTHOR); MODULE_DESCRIPTION(DRIVER_DESC); MODULE_LICENSE(DRIVER_LICENSE); -MODULE_VERSION(DRIVER_VERSION); -MODULE_ALIAS(DRIVER_ALIAS); +//MODULE_VERSION(DRIVER_VERSION); +//MODULE_ALIAS(DRIVER_ALIAS); #ifdef MODULE static unsigned int autoload = 1; @@ -3822,7 +3822,7 @@ static int usbvision_muxsel(struct usb_usbvision *usbvision, int channel, int norm) { - int mode; + int mode; int audio[]= {1, 0, 0}; //channel 0 is TV with audiochannel 1 (tuner mono) //channel 1 is Composite with audio channel 0 (line in) //channel 2 is S-Video with audio channel 0 (line in) @@ -3840,10 +3840,10 @@ } // set the new channel - // channel: 0 = Television, 1 = Composite, 2 = S-Video + // channel: 0 = Chan White, 1 = Chan Green, 2 = Chan Yellow, 3 = Chan Red switch (usbvision_device_data[usbvision->DevModel].Codec) { case CODEC_SAA7113: - mode[0] = 0; mode = 2; mode = 1; //modes for saa7113 + mode[0] = 0; mode = 2; mode = 1; mode = 3; //modes for saa7113 break; case CODEC_SAA7111: mode[0] = 0; mode = 1; mode = 7; //modes for saa7111 @@ -4171,17 +4171,20 @@ } switch(chan) { case 0: - strcpy(vc->name, "Television"); - vc->flags |= VIDEO_VC_TUNER; - vc->type = VIDEO_TYPE_TV; - vc->tuners = usbvision->have_tuner; + strcpy(vc->name, "IN-White"); + //vc->flags |= VIDEO_VC_TUNER; + //vc->type = VIDEO_TYPE_TV; + //vc->tuners = usbvision->have_tuner; break; case 1: - strcpy(vc->name, "Composite 1"); + strcpy(vc->name, "IN-Green"); break; case 2: - strcpy(vc->name, "S-Video"); + strcpy(vc->name, "IN-Yellow"); break; + case 3: + strcpy(vc->name, "IN-Red"); + break; } PDEBUG(DBG_IOCTL, "VIDIOCGCHAN name=%s", vc->name); return 0; ===================================== I don't know how to detect this specific device between others with the same ID (like the original D-link one) Thanks, Dan 02-20-2005 14:18:01

RE:xanboo (modified 0 times) jsmmd Profile Am I reading this correctly that you can also detect the sensors when they are tripped via the above method? 02-24-2005 20:13:36

RE:xanboo (modified 0 times) jsmmd Profile I damaged mine. Anyone have one they'd like to sell? 02-28-2006 17:19:12

RE:xanboo (modified 0 times) RobWall Profile Does anyone have the orginal cd for the WIRED version of this system? The part number would be XXS001 03-22-2006 11:48:03

RE:xanboo (modified 0 times) seanwg Profile Hi I've got an Xanboo system; and I want to put it to use - anyone know if the USBVision source code supports the 4 cameras on the unit now? Sean 08-26-2006 11:55:43

RE:xanboo (modified 0 times) fireether Profile Ok, sorry for reviving something thats been dead for a while, but I've been re-researching into this device again. I basically passed the xanboo program for windows through IDA decompiler and while I cannot disclose the source due to copyright laws, I can disclose some things. The reason why I can is because the hardware is paid for, and I believe we're allowed to figure out the hardware in order to re-use it as long as we don't post any source code. I also ran xanboo using usb monitor (google it). Basically I found out that there are 3 endpoints - 0x01, 0x82, and 0x83. 0x01 is used for control. However, 0x82 and 0x83 are used for data input from the xanboo device into the computer itself. One of those is video stream (as far as i know) while the other is data stream. I triggered a sensor a number of times and monitored the packets. Basically normally 20 packets is sent, each with a length of 0x1bf or so. However, when a sensor is triggered, you get 20 packets each 8 bytes in length. So this leads me to conclude that 0x83 is for video, and 0x82 is for audio and sensor data. Lucky me, I worked on an I2C project not that long ago. I basically made 5 microcontrollers, each controlling 6 RGB LED's. Each microcontroller had a program that allowed me to modify the brightness and which color on which LED - individually. The 6th microcontroller controls the 5 others via an I2C interface. So when I used my analog audio oscilloscope on the pins connecting the wireless reciever to the main xanboo board, I identified the SDA and SCL lines. The only bad news is that the wireless board uses 3.3v, while my projects uses 5v. I dont have any voltage converter chips on hand, so I've been trying to get the driver to work and then monitor for I2C communications. As far as I can tell, the usbvision driver will use the saa711x module to search for I2C devices and it will find one. However, the PIC microcontroller used for the wireless board does not have native I2C capabilities. This leads me to theorize that its used to "bit bang" and basically what happens is that the driver - once connected to the xanboo device - will keep on getting the video streams and same time if an I2C event occurs, its reported to the driver by the saa711x device. However, the linux driver will find the I2C clients and then it moves on, it doesnt seem to have any facility to recieve I2C messages other than dumping them into the debug stream. However, I havent been able to really tell if the messages are being dumped. See, the Xanboo unit has a LED thats either RED or Green. When its "ON", its Green. However if its getting power and its off, its Red. I've compiled the driver and then tried to get VLC / Palantir to work with it, however theres a problem. I'm compiling usbvision on a sparc64 (Sun Ultra5) - and not on a x86 machine. So it seems to have a problem with Xanboo. It recognizes it and then when it tries to make a video device, it fails. So I brought in a newer kernel, yet it wont compile. Basically I gotta update alot of packages in the machine first.. And one other thing that I noticed.. When the xanboo device connecs, its LED stays red. But when something actually accesess the streams, it will turn green and "power up.". I noticed that the wireless reciever gets a voltage of about 0.7V during "powerdown" (red led state), but when it powers up, this goes to 3.3V. So it wont even get wireless signals from sensors until the board powerups. This fits in the theory that the microcontroller next to the reciever is a dumb bit-banging software I2C implementation - because this way it wont even "send" sensor signals on the I2C bus until its active. Why am I doing this? I have a bunch of sensors that I'd love to use. Each one is a "powerline" sensor, but can easily be modified hardware-wise to sense any kind of input. And wireless is alot easier than wiring the garage door, front door, etc to a central microcontroller that i programmed - that communicates with the computer via USB or RS232. I'd love to be able to remove the wireless module and interface it directly. However, the easier way may be to do it via software instead of via hardware - due to voltage difference and to the fact that I'm not sure what speed the I2C is operating at yet. Will update if I find out more. 06-08-2008 23:10:59

Reply to Thread | Printer | All times are PST Powered by UltraBoard v1.62

I-Appliance BBS General - NEWS, Breaking NEWS - linux-hacker.net BBS on CD Questions - User Groups in Your Town - E-Bay, Yahoo Auction LINKS ONLY (MODERATED) - Jokes & Humor - usdtv box I-Opener Areas - I-Opener General Posts - I-Opener Technical Stuff - I-Opener Technical Info Reference (MODERATED) WebSurfer Areas - WebSurfer General Posts - WebSurfer Technical Stuff - WebSurfer Technical Info Reference (MODERATED) Other I-Appliances - Virgin Webplayer - WebPal - MailStation - 3Com Audrey - ThinkNIC / Oracle NIC - Gateway/AOL Connected Touch Pad - Philips/AOL-TV - ACER NT-150 STB - MSN Companion - Compaq IA - Emachines IA - IBM NetVista IA - Intel dot.station - MSNTV2 Network Computers - Fujitsu-Siemens Scovery Linux Net Computers - GallantWeb Server Consoles - Dreamcast - xbox hacking Web Pads - Epods One General Post - Panasonic CF-01 - Fujitsu Stylistic 1200 - Cybiko Thin Clients - Thin Clients DigitalVideoRecorders - DTV Recorders, Replay, TiVo, Etc... - Tivo Hacks Linux - Midori Linux General Board - ITX MotherBoards Single Board Computers - Earth Computers mARMalade Elite Member Area MISC Areas - The Swap Meet WE TAKE NO RESPONSIBILITY FOR ANY TRANSACTION HERE AND NO COMMERCIAL POST PERIOD !!! - Wireless Net - Cameras - Robotics - Routers/Gateways - Mattel JuiceBox