As far as programming a standalone unit, I don't think we'd be trying to port much code. The 'client' in such a case would also need to handle all the hardware functionality, so it'd be totally different than running an application on top of an OS, unless there were a full embedded linux board or something. Which is one reason I think the smartphone port makes more sense - no overhead of handling an interface.

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.

When I read through this thread I remembered that the OLS breaks out the Pins RX1,TX1 on header JP1.

AFAIK in the beginning the PIC used to communicate with the FPGA over this serial line. That was changed to SPI later on. Now it looks like these pins RX1,TX1 are not used for anything. Is there a chance to control a Serial2Bluetooth and/or Serial2WiFi board over these two pins? That would make it very easy to connect any kind of communication hardware(BlueTooth,WiFi,Ethernet) to the OLS. Are there major problems to be expected with the PIC-(FPGA?-)Firmware changes to make this work?

I love the idea of an android or ios client that works from bluetooth. The bluetooth serial is a standard, and I assume both big pad OSes support it natively. I would prefer to see it on android because you can run dev-apps without jailbreaking.

We'll pay a $100 bounty if someone releases an open source test client. Something able to use bluetooth serial, grab samples, and show a crude graph on an android device (ios is ok too I guess). It's not a big prize, but it might be a cool bonus for someone already working on something like that.

I think it'd be cool, and I'd totally be willing to plunk down a few hundred dollars for a nice, community-designed bench logic analyzer, even if a little buggy, but I don't think a true community design has the attention span to make it happen without serous bugs and developmental lags such that it's no longer worth the hundreds of dollars hardware cost.

imho there is no reason that the should not be somthing like the dso nano but have the logic sniffer built in.

I agree completely. I would love to see it, but I think it is one person's labor of love.

AFAIK in the beginning the PIC used to communicate with the FPGA over this serial line. That was changed to SPI later on. Now it looks like these pins RX1,TX1 are not used for anything.

<geek alert>The RX/TX were always just extra pins, for future/experimental use. In the beginning there was a second UART, but it was between the PIC and FPGA and placed with peripheral pin select.</geek alert>

Is there a chance to control a Serial2Bluetooth and/or Serial2WiFi board over these two pins? That would make it very easy to connect any kind of communication hardware(BlueTooth,WiFi,Ethernet) to the OLS.Are there major problems to be expected with the PIC-(FPGA?-)Firmware changes to make this work?

pppd has already done this. It rolls over to serial if there is no USB I think. There were some minor changes to the firmware, mostly to setup the UART and do UART instead of USB buffers. It may even be in the latest release already (?)

ian wrote:....pppd has already done this. It rolls over to serial if there is no USB I think. There were some minor changes to the firmware, mostly to setup the UART and do UART instead of USB buffers. It may even be in the latest release already (?)

Is there a place where to look for more information on this?Bluetooth connectivity would be useful for my Desktop Machine as well, one less USB-cable on the workbench!

Tarloth wrote: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.

In wich task can I help?

I think the difficult part is on the OLS hardware side: connecting the bluetooth hardware and making the OLS talk over the bluetooth connection instead of using the USB. (Making the Client aware of the Bluetooth-connection to the OLS doesn't seem to be a major problem to me.)

I also read what Ian wrote about this ....

Ian wrote:pppd has already done this. It rolls over to serial if there is no USB I think. There were some minor changes to the firmware, mostly to setup the UART and do UART instead of USB buffers. It may even be in the latest release already (?)

... but I don't understand it. There is support for this in the PIC-firmware of the OLS already??? I think I followed every release, an also read release notes when available, so this would be a big surprise!

I think the difficult part is on the OLS hardware side: connecting the bluetooth hardware and making the OLS talk over the bluetooth connection instead of using the USB.

Assuming the bluetooth dongle is a transparent serial port for PC, and another transparent adapter on the target, then there is no change required. pppd modified the source to use the UART already. The only question is where is that code ;) I have been a bit tied up today, but I will try to find it. Maybe pppd has a thought too.

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.

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!

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.

This is the second time you have described the USB on the OLS as limiting, a compromise, or not real. I'm not sure what you mean, but I need to defend our design choice :) It is not a compromise, it is almost the ideal solution. USB CDC is real USB, it is driver-less on all modern OSes, even stuff with USB OTG can be made to work with USB CDC, it is an open and well-known standard. It is not limited to UART baud rates, it works at 3M+ depending on how the individual OS throttles CDC protocol, which is more than fast enough for the small number of samples in the OLS. It also makes the whole project possible - no changes were required to the software client or the FPGA core to get it going. In my mind the transport is separate from the protocol, so I don't see why changes to SUMP protocol would be needed to support different USB transport method.

The firmware is open source, and the client is open, so the existing hardware and software can be changed to "real USB" (HID? USB bulk transfer?) without any new hardware. Nobody has shown an interest though, so I don't see a high demand to shave off a second from sample downloads, or to move to a more temperamental and complicated USB setup that requires custom drivers for all OSes.

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.

The dongles I have, and I think the ones pppd used, are serial links for peripherals. You can connect it to a UART and it forwards the UART, over bluetooth, to wherever. The PC/tablet/etc does not need a matching dongle, any bluetooth receiver will work. While the PC/tablet must have drivers for its bluetooth receiver, the bluetooth UART appears as a standard serial port to applications (massively simplifying development).

Since most tablets don't support USB OTG yet (in software or hardware), a bluetooth emulated serial connection it a logical way to get data into a variety of devices without special hacks. pppd has made a bluetooth dongle that uses the OLS serial header to power the device and create a wireless link. It's a very straightforward module, anyone can get started (sans power pack) for a couple dollars. There is no plan to make new OLS hardware with a wireless data link on our end, at all. I think everyone here is talking about some external hardware to handle this part, and pppd has already done this.

The bluetooth/UART connection is easy to test on a PC, just fire up the client and point it at the bluetooth virtual serial port. It will be slower and flaky, no doubt about it, but it works with no changes.

To extend to Android or iOS devices, a new client will be needed. I think that is the crux of the discussion. The hardware is uncomplicated, writing a new client for either platform is going to be a major undertaking, especially when even PC-based C clients like sigrok can't seem to make a release.

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

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

It was a pain to get going, but when it worked it was just like a serial port on the PC. I opened a terminal and talked to the microcontroller over a 115200 (?) bps serial connection. I think maybe there was an AT command or two for optional settings, but it would be no issue adding that to the OLS firmware when the legacy UART is engaged.

I have not yet tried it with rxtx, so I would defer to your experience. I googled it though, and saw a few problems and several successful attempts. It looks like in general it can work, but again, I don't speak from experience - you may well be right.

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?

If USB penetration was the same, no. USB provides power, and it takes no extra parts to support it. RS232 needs the MAX chip and a bigger, more expensive connector. USB is cheaper for us as a manufacturer.

It's been really a long time since I did this and since I am not really a MicroChip guy the code was just modified to work. I remember I got some hints from Ian so what I really had to do is uncomment a few parts of the code. In the version I could locate on my HDD it you activate the UART by pressing the update button after it's already powered up. I will try to help more after the weekend.

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.