Dangerous Prototypes

Hi:

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.

THANKS TO ALL FOR HIS WONDERFULL WORK!

[quote author="Tarloth"]Hi:

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.

THANKS TO ALL FOR HIS WONDERFULL WORK![/quote]

is there a wide interest for a standalone device that would work with the logic sniffer/bus pirate?

I'd be a fan of that. I can't imagine it'd be terribly hard since iPhones have raw UART available. The biggest problem is that they don't run java.

Some time ago I experimented with a Bluetooth enabled OLS. It worked fine with the desktop client and my idea was to create a iOS/Android client that would work with it. I was kinda busy with other stuff, I still am, but if there's enough interest and there are devs willing to help I might get back to this project.

[quote author="alexwhittemore"]I'd be a fan of that. I can't imagine it'd be terribly hard since iPhones have raw UART available. The biggest problem is that they don't run java.[/quote]

the Linux board, if paired with a graphic LCD could be used for that purpose. assuming somebody writes the code.

Eh, at that point you're just making an embedded computer. You might as well turn it into a bench logic analyzer, and then cost is already way above the current $50. Not that it wouldn't be super cool! But I like the bluetooth idea more. Bonus points for electrical isolation.

I'd love to help out, I imagine the biggest missing piece is making a mobile client? I'm not too great at iPhone development, but I know my way around obj-c and could probably do it with hardware available. Do you have a functional Bluetooth wing now?

I have a BT adapter converted to work with OLS. I started designing a daughter-board with a LiPo and auto-switching power usb/battery. I modified the OLS firmware to check for Bluetooth presence and failover to USB when BT is not present.

I will gladly give the iOS/Android client a go since I am going to refresh my knowledge on coding for this platforms anyway. I can't promise anything like when it's going to be ready since I am known to underestimate the time required to accomplish certain tasks and I have a few other projects which have been on my waiting list for a long time now.

I'm interested in trying my hand as well, but I'm in the same boat. Can we take this to a different thread or offline? My email is my username at gmail.

I'd rather stick to this forum. Secret projects tend not to be successful and I want it to be open source anyway. Maybe Ian could fork it into a new thread.

Pow! New thread.

Secret projects tend not to be successful

Love it. 100% true. Feed the google and others will come in the future :)

I would love to do Android or iPad app. I suppose one bluetooth serves them all. We are also working on ADK, so I will be messing with that soon. I have both device types for testing.

WOW!!!!! This was FAST!

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.

Hey all: pppd/ian: I didn't mean to suggest closed development, not at all! I just think we've already done a nice job hijacking an old and only somewhat related thread to get here :).[s:]I've created a new thread to talk about the mobile client/bluetooth hardware idea here:

viewtopic.php?f=23&t=2916 (http://dangerousprototypes.com/forum/viewtopic.php?f=23&t=2916)

pppd, I'd love your response to my question there, what is your actual bluetooth hardware setup, does it work, and can I copy it from you on my end so I can start playing with making a BT-based iOS client.[/s:]

As for the idea introduced by sqkybeaver of using a graphic LCD and embedded linux board, I've just started a thread about making a benchtop variant here:

viewtopic.php?f=23&t=2915 (http://dangerousprototypes.com/forum/viewtopic.php?f=23&t=2915)

Spoiler: 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.

EDIT: Didn't realize the thread had already been split from the beta testers thread, sorry guys! Benchtop vairant still stands though, I think that deserves its own thread.

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

[quote author="sqkybeaver"]imho there is no reason that the should not be somthing like the dso nano but have the logic sniffer built in.[/quote]

I don't disagree, but I think that there is one key difference. Typically, if you're looking at analog waveforms, you're doing something like debugging a component or subcircuit. Using the waveform involves tweaking analog pieces of the circuit.

On the other hand, when you're using a logic analyzer, what you're debugging is generated by digital components or subcircuits, which are almost always, these days, software generated. It's either FPGA HDL you need to modify, or microcontroller code in order to fix your serial or parallel waveforms. If we still used 7400 chips all the time, that wouldn't be so true, but discrete logic isn't typically a major part of today's workflows.

I think what that means as far as tools go is that it's useful to have a standalone scope - you're not limited by bandwidth of a USB bus, you don't have to have a computer present when all you're using it for is circuit debugging, and so on. Intrinsically, it makes sense to have a scope next to your circuit.

But on the other hand, if you're using a logic analyzer, you're almost certainly modifying software and reloading that into your circuit to try to get your waveforms correct. So you've already got a computer on your bench, and you're trying to match bytes and timing from the LA to what your software SHOULD be generating. In that case, it's far more useful to have the waveform data in the window next to your IDE. For that reason, I don't think that I'd find a bench or even standalone handheld LA especially useful. If it's an extra $30 for the bluetooth hardware to use my phone as a display, that's worth it for the novelty and portability in certain situations, and for that matter, bluetooth could replace the USB cable to a computer in the first place. But I don't know that I'd pay $100+ for a standalone unit INSTEAD of my USB unit, whereas I totally would for a scope.

Additionally, there are key interface differences too: Scopes are used on analog waveforms, and LAs on digital. Changing the parameters on a logic analyzer involve punching in integer values and clicking checkboxes corresponding to boolean values, all easy and comfortable to do on a computer in a software interface.

On the other hand, getting your waveform correct on a scope involves turning knobs for amplitude, time delay, trigger value, and so on. This is far more awkward on a computer, especially for the continuous nobs like cursor that can't be replaced by a 0-100% slider. I will always prefer nice smooth knobs to interact with my analog waveforms, necessitating a nice big standalone product. I think even the DSO Nano/Quad come up short here.


EDIT: Forgot to say, you mentioned integrating something like the OLS INTO something like the nano. I would definitely be in favor of a standalone mixed signal scope. That would be one MAJOR case in which a standalone product makes lots of sense.

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.

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.

Hi,
I would really like to see the OLS going wireless!

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

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 [tt:]RX1,TX1[/tt:] 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?

Eberhard

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 (?)

[quote author="ian"]
....
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 (?)[/quote]

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!

Eberhard

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?

[quote author="Tarloth"]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?[/quote]
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 ....
[quote author="Ian"]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 (?)[/quote]
... 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!

Can anybody shed some light on this?

Eberhard

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.

Sorry for my bad english

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.

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

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

No worries, your English is almost perfect :)

It sounds like you have way more experience with the SPP devices. I have only played with this one and a microcontroller with MAX RS232 chip:
http://www.sparkfun.com/products/8495 (http://www.sparkfun.com/products/8495)

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.

---

Ian:

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 (http://http://www.ebay.com/itm/Wireless-Bluetooth-V2-0-Transceiver-Module-RS232-TTL-/380368700301?pt=LH_DefaultDomain_0&hash=item588fbdc38d#ht_3590wt_1270) 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.

[quote author="Tarloth"]
For example this small board (http://http://www.ebay.com/itm/Wireless-Bluetooth-V2-0-Transceiver-Module-RS232-TTL-/380368700301?pt=LH_DefaultDomain_0&hash=item588fbdc38d#ht_3590wt_1270) 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.

[/quote]

Sorry to slightly hijack this thread, but since I've just bought a couple of bluetooth boards like those, I'd be curious to know what firmware is the most reliable for them.  Can you point me to a web page with good information about reflashing them?
Thanks.

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?

[quote author="Tarloth"]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?[/quote]
Thanks for the information.  If you find out anything more it would be great.  As far as a dongle, I'm not sure.  I've got a fair number of programming dongles but it depends on what these boards need.  Since I haven't looked into what it takes to reflash the firmware I really don't know.

But, with micro controller the dongle has made? With more information my friend maybe help you.

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 (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.

My point isn't to say that a standalone logic analyzer (or MSO like we're talking about), and especially a pocket-sized portable one, is useless. My point is just that the goals of a LA are much more in line with a pc-teathered unit, so for the ease of design it affords, the USB-based LA is probably the best compromise.

Yes, I agree that the meaning of ols it´s not to convert in a device with screen and complete logic and storage, BUT, if we can transform the client in something that would be use in portable OS like android or IOS, somebody (like me) can use a cheap tablet (60 dollars in ebay) and do the tasks without the extra load of a complete laptop. I think that was the meaning of writing the client in something """"portable"""" like Java, but portable it´s not as universal than the software vendors claims. I believe that this feature it´s even less pretentious that thinking an expansion wing that adds an oscilloscope and adds it to the client and really not understand why some users could be oppose to the extension of client to other plataforms.

For me that would be a big improvement because the people that prefer a desk station use it, if prefer laptop uses it and off course  if prefer something more portable use it too. All scenarios are cover and the OLS not change essentially. Even the same person can use OLS in different scenarios. In my home I use a laptop in my electronic desk and has not problem with actual client and OLS, but my use of OLS it´s 90% as serial ports decoder and often I need it in the field in rough conditions. If I could use my phone (or a 7" tablet) as a client and connect to the OLS I´m very very eased carrying all the stuff and gain more battery time. Even not need a screen that show 16 channels, with 5 or 6 channels I´m satisfy and then a small screen do the trick.

That was the trigger of the thread. Somebody says that would be great use Bluetooth , I´m very happy with the USB but if somebody implements a stable solution in BT I´m very happy too because improve the complete design.  Ethernet or WIFI would be a big improvement too because both do the galvanic isolation (as BT does) and permits use the client far away from OLS board and that would be useful for certain users. I´m very happy too if this was implemented, but none of this improvements in communication port are necessary to use the OLS client in portable OS. Please, let´s put some order hear. One thing it´s extend the client to other OS (does not imply any electronic change to the OLS) and other thing it´s to add other communication channels to OLS. The only improve that I ask in this thread it´s to increase portability in OS, all of rest it´s welcome but not necessary to do the extension to other oses.

Thanks and sorry again for my bad english

wifi/ethernet require complete redesign. BT will work right now on existing obls. You just need to connect the BT module to the serial port of the obls and write a client for your phone/tablet. There's python client being developed iirc and android can run python hence - there's the client - just add bt module to the serial port of the obls and there you go

Arhi, where are the python client? I didn´t like too much python but if works it´s good. Thanks for the advice.

[quote author="Tarloth"]Arhi, where are the python client?[/quote]

python client is here on the forum (http://http://dangerousprototypes.com/forum/viewtopic.php?f=57&t=2476), I have not followed how far they went with it but you should try it out. The python client home page (http://http://melwilsonsoftware.ca/logic-sniffer/index.html) has some interesting screenshots so it looks it works.... it might need some tweaking to get it working on android (I'm neither a fan of android nor python so as you might expect, haven't bin using none of them)

Arhi:

I´m not a fan of android or python, but saddly I can´t buy a very cheap tablet with regular linux installed (or compatible of course). I´m following several users that tweaking his cheap tablets and install ubuntu and if I can do that, Android it´s putting in a garbage bin five minutes latter!. It´s very important to me running OLS in a cheap more portable device than a laptop. THANKS for the client  URL I now read this