For example. I search my desk and found 4 or 5 BT USB dongles that cost $1 (yes ONE dollar) and has only one integrated chip NOT FLASHABLE Conwise CW6626. I not find any data sheet and Conwise did´n answer my mails, but in his page has a small data to a (previous?) cousin http://www.conwise.com.tw/spec/CW6621web.pdf .In his datasheet claims
" Bulit- in primary profiles including Generic Access Profile(GAP), Service Discovery Profile(SDP), Serial Port Profile, and Headset Profile"
But take it easy, the SPP works only when all the planets align with the sun! In other hand SDO and headset profile works like a charm!.In the data sheet says that can be used via USB, SPI or UART but I have not pinout. In a russian or german site says that all of the BT chips from Conwise are OTP and the are not flashable. I don´t know. With the foxconn drive works most the time good even the spp, but sometimes, without a know reason, simply stop to work. In linux works but not SPP. My friend can do nothing with this dongles, use better ones with one chip for radio and one micro controller for manage the radios and has the information for the chip.
Both dongles claims the same, but they are very different, but, in the "cheap grade" of BT dongles I only see two models. Like mines and like my friend uses, with different micro controllers but same radio.
Sorry, I didn´t know one. One friend of mine program from scratch a couple models of that boards and work OK without problems (with the original soft the same board fail a lot) but do this job for your work and it´s confidential. Maybe I can ask him if he can donate the sources but he """hates""" the open something and I see hard to convince. For sure he can oriented us, but, I ask him in the next days and use OLS as temptation. Sorry for not can help better.
In case of he can/like help, have you a dongle to copy the ucontroller code part?
Yes and no. I have experience doing programs that communicate to BT devices and see the instability in connection in the field with a lot of different users. Perhaps for a keyboard it´s not a problem that the device try in background re establish connection two or three times per minute, but in a logic analyzer may be a real problem.
But I wrote to that the problems are inversely proportional with the price of the dongle, and actually when I think in dongles or chips for BT in OLS I take in mind dongles with price proportional to OLS. That is, I think in dongles for < $5, and all of this that I probe have an not uniform behavior in different PC and OS´s. Someones work good, someones work good in some circumstances only and someone not work stable at all. The dongle that put in the link cost more than a complete Android tablet! I presume that it work perfect, it comes from an excellent seller, and again, cost a lot compared with other BT dongles. In my experience the dongles have less differentiation in hardware than in software and perhaps all the cheap modules reprogrammed works great allways.
For example this small board reprogrammed works great in all cases, but without re flashing, it´s trial and error. In contrast, usb bridges works great most of the time.
BUT, I´m not oppose against BT, I simple say that the problems are very different, one it´s the client OS, other it´s the use of something wireless to isolate the OLS with the PC and other case it´s to use OLS in other environment for example as Ethernet device remote to the client.
When I end several delayed task I work in traslate the client to a most general OS platform, but by now I´m useless because I cant offer help in Java. Sorry again.
Sorry, I read again my answer an discover that I miss an important part of the idea (sorry, but write in english it´s an effort and it´s not fluid at all for me, lost in translation).
Off course that I assume that you means that you are using the BT profile SPP, but BT is not an USART and the profiles in cheap dongles are very poorly implemented. A lot of things can do fail in the over simplification of BT to the USART. The suceed to implement the profile it´s left behind the dongle that you use in your PC or the restrictions/implementations in the embeded BT in the device. For example a lot of dongles lack most of the profiles but curiously permit raw BT, iPhone restrict the use of SPP to some devices only and I believe (for the devices that I use) that the half or more android tables with a crapy BT chip loose the profile without explanation. RXTX has a lot of problems too with cheap dongles or dongles that poorly implements profiles. I have not good experience in pairing BT devices using SPP, in all cases I see the other device but the profile not create the virtual port. In the other hand, only in few cases a SB bridge not connect as I expect or a etehrnt connection fail. The possibility of a crash in my experience it´s inverse with the dongle cost and I can´t assume that a cheap phone or device have a good profile implemented or in the iOS case, the apple restrictions are in most cases unexplained. Sorry for the missing part
Hi Ian, I´m sorry if my english isn´t good enough to explain me.
I read part of sources and If I not in a mistake the clients use the RXTX libraries to access the STANDARD VIRTUAL SERIAL PORT generate by the OS in the PC side when you connect the USB port programmed in the PIC. At the PIC side, you use the standard library that negotiate with the USB controller at the PC side the creation of a structured communication that permits simulate a serial port.
Since FTDI and others start working in this area to do an easy implementation to their bridge chips, all modern OS (as you say) take this simplified protocol and creates a VIRTUAL UART PORT in the same way that HID talks transparent to some Human I/O selected devices.
In this sense it´s that I affirm that the OLS uses finally an USART, enhanced by the transport over USB, but only is a USART. Correct me, but if I alter the firmware of PIC at point that talk to a native USART instead to USB library USART like functions (like pppd says that do) all of the rest of client and OLS can work with a physical legacy USART.
Good enough for the inmense vast of low velocity projects and as you say, the data transmitted by the OLS it´s a small packet and the time involved by the sum of time to transmit info+client representation not justify a native USB implementation.
Is that a problem? I don´t think that. A lot of commercial devices uses this strategy to establish bridges that can talk to small processors and reduce cost when the task to implement don´t need all the computational power that implies a full spec USB.
BUT, when I say that a device uses a full USB implementation I say a totally different situation. USB enhance in many aspects the serial communication and off course, it´s correct, it´s a serial protocol, but differ from USART more than USART differs from the printer port! A lot of more bandwidth implementation can be do with USB, if the OS support even real time tasks. Off course implement such task or devices implies a big effort in both side of the USB link and off course implies drivers to do.
Some devices can work with a USART and some not. For example oscilloscopes, external HD, cameras and other bandwidth dependent devices uses full USB implementation, OLS not need that and uses a virtual USART implementation. Correct me, but if all PC´s or laptops were still equipped with a legacy USART, OLS will were implemented only a legacy USART with a cheaper PIC Isn´t it? In this sense I applaud the designers to maintain a spartan design focused in usability an cost effective. BRAVO!
But when somebody says that change the protocol communication some point will be considered, It´s NOT TRUE that a bluetooth in a generic device talk in therm of USART protocols and the bluetooth dongles not necessarily be managed by RXTX. Again, It´s a serial protocol too, but not USART one, it´s seems more liked to a Ethernet stack.
Please search in google "RXTX and bluetooth" and see that in the real word happens. A lot of problems in OS´s and all dependending wich dongle you use and generally, the cheaper the dongle, the greater the problem and in general with native PC motherboard BT, RXTX not see in anyform. A completely different problem if you says that use a specific devices that do a USART-Bluetooth bridge in both extremes. Only in this case it´s true that you affirm and BOTH the OLS board and the Client communicates transparently without major changes. If only put a USART to BT in the OLS side, then you need to use OTHER library that RXTX in the client side. Fortunately, standard JRE manages most of BT and then only you need to reprogram a small part of client.
But hardware will be added to the OLS, I I not see wrong this hardware it´s important compared with OLS cost and this it´s OK but even convert the link to BT not do that the client works in iPhone.
And ONLY that it´s that I say, data link and OS implementation are very isolate tasks and based in that you wrote extend this client to iOS or Android it´s maybe impossible or very far objetive. That was my start question, the answer then, not inmediate plans to port OLS to Android or iOS.
Sorry if my bad english not explain accurately that I not critic the OLS designs, simply says that it´s not the same use a virtual USART that use natively WIFI for example. Sorry again
The bluetooth dongles that I use aren´t a transparent serial port. They need specific drivers that manage it as network point.
Exist modules and products that are Bluetooth bridges like the SPBT2532C2 or the LMX9838 (I never use it) that simplifies the connection but at pc/phone/tablet side still it´s necessary to have some kind of serial port to use this modules as wireless modems. They aren´t cheap like a standard dongle. If somebody likes to use the OLS throw a native BT at PC side it´s needed to use some kind of driver to manage BT and change the software protocol to manage the BT caracteristics and in the final the serial speed of a BT is lower or equal than in an UART.
It´possible but I have in mind that the OLS hasn´t a REAL USB because compatibility problems with protocol used by the sump and then simulate a serial port over USB (limiting the USB capabilities) to simplify that and reduce costs.
I think that this it´s an important point, all the development it´s center in an UART bridged throw USB
At the moment I think that exist TWO different needs in this post and both are very independent and isolates
a) Extend the range of OS of the client to the OS´s used by portable devices, for example Android and iOS. b) Change the datalink from USB to something wireless.
Point A needs only software considerations and if not exist compatible Java Machine for the OS then it´s impossible without rewrite all the code. It´s """simple""" but I can´t do that because I not program Java (I hate it, no offense please!) and then can´t offer any help and feel useless. SORRY. I know that t´s possible to recompile JAVA code to Android but it is not transparent at all.
Point B implies software and hardware updates, increment final costs and several trials and error to put to work and think that it´s a mayor foot step to actual OLS.
If my opinion count (I a newbie to OLS and don´t like to bother or disturb to people that work a lot and do a worderfull product), I prefer to put the same effort in update the FPGA specs, work in a native USB or Ethernet protocol, implement trigger advanced features, etc, things that affect all the users and improve the OLS usage.
Regarding the bluetooth connection, keep in mind that the PC is not as standard management as one might expect and that can bring many complications to the client.
Exact! I believe that the actual work it´s fantastic and the "only" desirable thing is port the client to non-PC OS. USB it´s sufficiently good for most people. If any needs isolation (that it´s REALLY good) simply make a miniboard with the adum4160 and put an independent power source to the OLS side or isolate with some device each of input channels. Actually, iPhone and iPad hasn´t control of the USB interface, then this users can use a Bluetooth-OLS adapter (cost some dollars) and implements the driver change for iOS or use a serial adapter in the dock ( forum not permit to me put URL, but if you google find ircuits and info to build a serial to idock connector) and connect to the PIC via RS232 channel or making an USB bridge. Sounds weird to do a serial to USB to use a USB to serial chip but if it works....
Everyone smiles when the original project continues untouched and standard.
It sound´s great, but DSO nano uses an ST ARM CORTEX Chip in it plus an FPGA to manage the ADC´s. This option implies I think to port all the software to a ucontroller. I´m working in this ST micro controller now but I doubt that the java client may be implemented without big (big!) changes. If the OLS client were written in C, I can maybe try to program a library that support the direct compiling of real client code in a small limited interface, but Java virtual machine demands more processor power and a better OS than a micro controller support . I.E. I think that porting to something like DSO nano demands a complete rework of code and I doubt that justify reinvent the wheel again. But it would be FANTASTIC to have a protocol analyzer with the impressive specs of OLS in a device like the DSO nano :-)
Alex has a point when says that when we work in serial protocol generally I reprogram the microcontrollers that comunicates with a computer in the table, but, porting to other OS like Android permits that. Somebody use anexed to the same computer, somebody travels with the OLS to field to see what the serial buses says when they are free in the wild (my case).
If it´s possible to work in both extremes with the same OLS board, id est, with a standalone hand and cheap device to gain portability or with a computer in the laboratory to gain performance, I think that the project upgrades to better status.
I agree, a "standard" communication port with a porting to several OS grantee freedom to everybody. Somebody choose a old or new laptop connected to the OLS, other can build a mini-ITX computer with screen or other can use his favourite device to talk with the OLS. I prefer respect the full independence of the actual OLS.
I love all the ideas!. I think in an embedded computer but at cost comparison it´s preferable to buy something massified. In ebay you can buy a 7" tablet with wifi and android 2.2 for $70, not the best, not so reliable but with an 800 Mhz processor, touch screen, wifi and a lot of memory it´s by far more cheap that buy an embedded computer (I think).
It´s true that you can integrate the FPGA to an existing board (or a mini-itx motherboard) and then speed all the process, but perhaps somebody that knows the costs implies in building something like that may put some light in possible costs of the whole thing. Indeed I wasn' t bought the OLS yet waiting if somebody propose and alternative that not be constrained by the simulation of a serial port. Some Wi-fi flavour, Ethernet or pure USB sounds better for multi platform BUT I respect the solution that was used and understand the compromise in their implementation and applaud that you can do something that works!. It´s by far better that any non implemented idea.
I have my time really constrained BUT I love and support 100% the open projects, I offered to do specific tasks in C/C++ or help in something that I result useful. Not a lot of time, but I like to help.
I not sure where post this question, but somebody plan to port OLS client to Android? Sorry for this question but would be very comfortable to use the OLS with a "cheap" tablet instead a notebook or PC. Even buying the tablet only for the OLS the total cost it´s several times lower than any other autonomous Logic Analyzer with similar specs.
