I need to implement an OPOS service object for a scale, specifically a USB scale if it is possible. I have read and checked out all documents and sources from Monroe Consulting Services about OPOS but haven't found any source linking to USB devices. I would like to know if someone out there as implemented OPOS service objects for USB devices. Thanks in advance.
I have implemented a few OPOS Service Objects that communicate over a USB Interface; some require hardware convertors (such as a RJ12 -> USB-B) and others can operate under a VCP (Virtual COM PORT).
Curtiss Monroe does provide a CCO (Common Control Object) for an OPOS Scale, so it is definately possible to implement an SO. Also.. what is the manufacturer and model number / hardware ID of the specific device?
Most retailers / hardware vendors provide the specific OPOS Service Objects for you so you may not even need to explicity create one yourself. If you are confident that you do indeed need to create an SO, it's important to consider if the application will use POS For .NET Service Objects or Legacy (UPOS) Service Objects.
Hope this information was useful. A.
Related
I am doing some research on the WebUSB API for our company because we are going to start to manufacture devices in house.
Our current device manufacture comes with an application so the team can plug the device into a computer and diagnose it. Their application allows us to read outputs from the device, as well as pushing commands/configuration to the device over a wired connection.
Since this device is 100% ours, we are also responsible for building out the diagnostic tooling. We need some sort of interface that allows a user to read outputs and send commands/configuration to the device over a wired USB connection.
Is the webUSB the correct API? If not, what are some suggestions for accomplishing the requirement? Are we limited to building some sort of desktop or mobile application?
I would recommend resources below to read to help you understand if the WebUSB API fits your needs or not:
https://web.dev/devices-introduction/ helps you pick the appropriate API to communicate with a hardware device of your choice.
https://web.dev/build-for-webusb/ explains how to build a device to take full advantage of the WebUSB API.
From what you describe, WebUSB isn't strictly required but won't hurt either.
First and foremost, you will need to implement the USB interfaces reading data and sending configurations. It will be a custom protocol, and not one of the standard USB device classes such as HID, video or mass storage. The details of the protocol and if you use control, interrupt or bulk transfers is your choice.
I'm assuming you will connect the devices to Windows PCs, and you likely don't want to put money into writing device drivers. If so, the easiest approach is to add the required descriptors and control requests required for Microsoft OS 2.0 Descriptors. That way, the WinUSB driver will be installed automatically when the device is plugged in.
Using the WinUSB API, a Windows application will then be able to communicate with the USB device. No additional drivers are needed. (On macOS and Linux it's even easier as you don't need the Microsoft OS 2.0 Descriptors in the first place.)
On top of that you can implement the additional descriptors and control requests for WebUSB. It will provide the additional benefit that you can write a web application (instead of a native application) for communicating with the USB device. (Currently, you are restricted to the Chrome browser.) WebUSB devices should implement the WinUSB descriptors as the alternative (.INF files, manual installation process) is a pain.
The already mentioned web page https://web.dev/build-for-webusb/ is a complete example of how to implement it.
We're designing a Bluetooth LE peripheral that implements some primary GATT service and needs to advertise the existence of the service as well as a few bytes of data related to the service. The device is intended to connect to arbitrary consumer smartphones (therefore mostly Android and iOS). We use a 16-bit service UUID and plan to advertise the related data via the advertising data type 0x16 (Service Data - 16 bit UUID). Due to the limited size of the advertising PDU, we'd like to avoid any additional advertising data, most notably we'd like to avoid advertising the same UUID also via data type 0x03 (Complete List of 16-bit UUIDs).
As the device should be used with consumer smartphones, compatibility is a major concern and therefore the compliance with relevant standards is as well. A critical aspect seems to be that the smartphone OSes should be able to do efficient filtering for devices advertising our service, so the app may run and listen in the background.
A safe approach would be to advertise both, 'service data' as well as 'complete list of UUIDs', because all OSes are certainly able to filter for UUIDs advertised in the latter, but this would exceed the size of the advertising PDU. We could also configure the mobile's BLE scanner to return all BLE devices nearby, without any filtering and do the filtering in our own code, but this wouldn't be efficient and wouldn't allow to run in the background.
We did some testing with different smartphones (Android and iPhones, older and newer ones) and at the first glance filtering for service UUIDs when only the service data type is advertised, seems to work just fine. However, we couldn't find any documentation (neither for Android nor for iOS) that definitely states that this is a supported scenario, so we can't be sure that it works on all phones and also in the future.
The Apple Accessory Design Guidelines section 36.4 refers to the Bluetooth Core Specification Supplement, Part A and states the following:
The advertising data sent by the accessory should contain at least the following information as described in the Bluetooth Core Specification Supplement, Part A:
Flags
TX Power Level
Local Name
Services
[...]
The primary services should always be advertised in the advertising PDU.
However, this doesn't make clear which kind of advertising data type should be used and the same is true for the Android documentation.
With this context my questions are:
Is it a good idea to advertise the primary GATT service solely via the 'service data' data type?
Would this even comply to the Bluetooth Core Specification?
Is there any documentation for Android and iOS that makes clear, whether this is a supported scenario from the OS standpoint (I actually don't mean the OS source code)?
Are there any Android (>= 5.0) or iOS (>= 11) devices that would not be able to filter for service UUIDs advertised via the 'service data' data type?
What is the best practice in such a case, given the limited size of the advertising PDU?
Thank you for your thoughts!
I understand that Bluetooth profiles consist of other profiles and protocols. What I don't understand is exactly how Bluetooth devices interact with each other. For example, if you take any accessory that implements the A2DP profile and connect it to the iPad then the iPad will stream all audio output to it. This makes me believe that a profile is nothing more than a modular component in a well-defined eco-system. For instance, a web-browser can use any one of your choice of search-engines in the toolbar; would I be correct in saying that the iPad is the equivalent of the browser and the A2DP accessory is the equivalent of the search-engine? Would I also be correct in saying that the use of A2DP is entirely up to the device it's paired with? That is, Apple could have instead chosen (albeit unwisely) to make the iPad output only key-clicks and ring-tones to it, correct? So there's nothing inherent in the A2DP profile that says "All devices using the A2DP profile MUST output all audio to it" right?
I'm not 100% familiar with Bluetooth as a whole. I've been spending some time drafting a profile for BT Low-Energy, so someone might be able to provide insight on standard Bluetooth with a little more detail.
But, from what I understand, the profiles are essentially a large map of connected references. So the A2DP profile will have a list of attributes, or rather, a list of HEX values which point to attributes within the larger profile. These attribute are typically universally available to all profiles, but only implemented by the profile where they are needed. These attributes define some piece of information that is going to be transmitted. This profile needs to be on both device to communicate, because this allows to Bluetooth transmissions to be smaller by only referencing a commonly known definition of the data it is transmitting (rather than defining what the data is in every transmission like some communication types).
So for A2DP, the transmission might be something very simple like '0x1351458 0', which tails the device that whatever that profile attribute is, it's value is 0. So that attribute might be the "play" attribute, so setting to 0 might stop the music.
Again, this is how I understand Bluetooth profiles from the Low-Energy standpoint which tends to be more a transmission of state than actual data, so it might differ a bit with regular Bluetooth.
Bluetooth profiles are specifications of bluetooth protocols that are implemented on the host side in bluetooth protocol stack.
Following link by bluetooth.org will provide basics about bluetooth profiles
https://developer.bluetooth.org/TechnologyOverview/Pages/Profiles.aspx
Bluetooth Profiles are set of standard interoperable guidelines defined by bluetooth.org, to ensure interoperability between different bluetooth devices.
Bluetooth devices claiming to support bluetooth profiles, should get Bluetooth Qualification Board[BQB] certified for interoperability.
You can buy any device supporting A2DP and test with any tablet/computers[which has bluetooth A2DP profile supported].
A2DP is not specific to iPad. It is a generic profile that stands for Advanced Audio Distribution Profile for exchanging Audio between two bluetooth devices.
I have a couple questions:
In general, what is the general difference between the OpenNETCF.Net namespace and the OpenNETCF.Net.NetworkInformation namespace in the Smart Device Framework? There seems to be a lot of functionality overlap between the two. Is the OpenNETCF.Net namespace now deprecated in favor of the NetworkInformation namespace?
More specifically, I have a device with a wireless adapter. My goal is to be able to query nearby access points and then connect to them through my own user interface.
OpenNETCF.Net.Networking.GetAdapters()[1] gives me my adapter object representing the wireless adapter. Even though this is a wireless adapter, IsWireless and IsWirelessZeroConfigCompatible both return false. However, NearbyAccessPoints DOES return a list of nearby access points as you would expect a wireless adapter to do.
I need a way to add one of the discovered access points to the PreferredAccessPoints collection. I have not found a method to accomplish this within the OpenNETCF.Net namespace. The only way I've found to add an AccessPoint is through the AddPreferredNetwork() method of the OpenNETCF.Net.NetworkInformation.WirelessZeroConfigNetworkInterface class. The problem I'm having is that I've been unable to find a way to obtain a WirelessZeroConfigNetworkInterface object. The object returned by the NetworkInterface.GetAllNetworkInterfaces() method is just a plain old NetWorkInterface object, not a WirelessZeroConfigNetworkInterface object as I hoped. I'm sure this is probably related to the issue with IsWireless returning false in the NetworkAdapter object.
Is there a way to construct the WirelessZeroConfigNetworkInterface object even though the framework seems to think it is not wireless? It looks like the functionality is there as demostrated by the Wireless related methods of the NetworkAdapter object.
The history is a bit confusing, yes. Basically SDF 2.2 (or earlier, I don't recall any more) had everything in the OpenNETCF.Net namespace. When I was adding features in 2.3, I added a boatload of stuff in the OpenNETCF.Net.NetworkInformation namespace that paralleled the full framework. Some of that had functional overlap with things we had done in the wireless stuff, so I made the decision to move everything over to the OpenNETCF.Net.NetworkInformation namespace. I left the originals and marked them as deprecated to try to be friendly to existing deployments. The items you should use are the ones in the OpenNETCF.Net.NetworkInformation namespace.
Now on to how the stuff functions. First we query NDIS for all network interfaces. This gives us wired, RNDIS, wireless, etc - basically everything that the network stack knows about. NDIS, however, doesn't know much about "wireless" stuff - it does know some though.
Once we have our list of known adapters, we then ask NDIS if it's a wireless device - it can at least tell us that becasue the driver tells NDIS at registration.
Once we have a list of wireless adapters, we then walk them and ask the WZC subsystem if it knows about the adapter. WZC is an interface that knows everything about the wireless devices, allowing us to intereact with it through a common, published interface. If WZC does know about it (meaning the driver reported itself at initialization to WZC) then we create a WirelessZeroConfigNetworkInterface for it. If it isn't known by WZC, then we know it's wireless (NDIS told us it was), but we only have the NDIS methods for interacting with it.
NDIS doesn't give us a way to associate. It does give us a way to ask for nearby SSIDs. The Adapter interface you have, then, exposes the capabilities we know of.
In some cases the driver has a proprietary API to manipulate the WiFi settings (e.g. old Cisco cards).
What version of the OS is this you're running on? What WiFi chipset/adapter are you using?
I need to connect to a Bluetooth device through virtual COM port created in Windows. It's easy when the port has been already created during manual pairing procedure. But I would like my application to relieve an user from the manual pairing of a device. I would like to present all devices in the range, allow user to chose one, and then create virtual COM port connected with the selected device. I'm not trying to avoid the pairing procedure itself, but rather I would like to invoke it by my application.
I started getting familiar with Microsoft Bluetooth API. And then some doubts arose. I've been wondering what happen if some user would use different (than Microsoft's) Bluetooth stack? Is the Microsoft's API the real Bluetooth API, which have to be implemented by any other Bluetooth stack provider? Or rather each provider has its own API, and the Microsoft's is only one of many other?
Thanks everyone for valuable input. I'd like to summarize what I've found so far. The Microsoft Bluetooth API is not operating system API. Application written against it will not cooperate correctly with any other Bluetooth stack. It seems that applications which are intended to cooperate with multiple stacks need to provide some stack abstraction layer, and stack specific code for all of them.The other solution is to allow user for manual pairing of the Bluetooth device, which eventually create some virtual device in the operating system (e.g., COM port). Then the application can use standard interface of such a device.
I can't speak for the Microsoft Bluetooth API, but there are multiple Bluetooth stacks available for the PC platform (even more for mobile devices).
The underlying API is defined by the Bluetooth Core Spec and so all stacks should be able to interact, in fact it is mandatory that they interop or they cannot use the Bluetooth name and logo.
As to pairing, your going to have a hard time getting devices to pair if they have default security, which requires a pin code.
Things might be simpler in the (near) future, as the Bluetooth standard has introduced a new security model, secure simple pairing, which has a 'just works' mode that requires no Pin code. This is still stronger then the current security, except against Man in the middle attacks. However, it could be a while before you see the chips with this feature in PCs.
If you can change to using .NET :-/ I can recommend our library 32feet.NET.
For explicit pairing there's BluetoothSecurity.PairDevice. We can also create the virtual port for you, for example:
BluetoothClient cli = new BluetoothClient();
BluetoothDeviceInfo[] list = cli.DiscoverDevices();
BluetoothDeviceInfo selected = GetUserToSelectOne(list);
BluetoothSecurity.PairDevice(selected, pin);
// Ask Win32 to create a virtual serial port
selected.SetServiceState(BluetoothService.SerialPort);
However I really don't like virtual serial ports so I always suggest that people use a normal sockets connection using our BluetoothClient class, it will automatically handle a pairing request if required.
On Win32 we support the stacks from Microsoft, Widcomm/Broadcom, and BlueSoleil. On Widcomm there's no support for SetServiceState there yet, and their API has no support for responding to pairing requests. BlueSoleil should support both.
A brief user's guide is at 32feet.NET — User’s Guide, and all the class documentation is available at the main site http://32feet.net, the Widcomm documentation is only in our code repository at the moment.