Using TWAIN to capture images from a scanner, I'm trying to determine if the open scanner has duplex scanning enabled. I know that if I use the DG_CONTROL/DAT_CAPABILITY/MSG_GETCURRENT triplet to fetch the CAP_DUPLEX capability, then it will tell me whether or not the scanner supports duplex scanning, but I need to know whether or not duplex is currently enabled. Is there a capability that I can get that will tell me whether or not duplex is enabled, not just supported?
Ther is another TWAIN capability - CAP_DUPLEXENABLED which serves for that.
Related
I'm working with ANT+ protocol, to connect a smartphone with an ANT+ USB dongle, which is connected to PC where with SimulANT+. SimulANT+ is simulating a heart-rate sensor, which sends data to my phone.
Until now I have been using a non-encrypted channel to communicate, but there is also an option to make a secure connection between devices as is written in ANT Message Protocol and Usage document. It's called Single Channel Encryption. Do someone have some code examples on how to establish this type of connection?
It is true that ANT protocol can use a single encrypted channel - however this is not the case for ANT+. (See the differences between ANT/ANT+ here: http://www.thisisant.com/developer/ant-plus/ant-antplus-defined)
If you use encryption for your device it is no longer ANT+ compliant and therefore you are not allowed to use the ANT+ Network Key or frequency.
This is because ANT+ aims to ensure interoperability between different manufacturers sensors/displays. If the channels were allowed to be encrypted, this would defeat the purpose ANT+.
Therefore if your goal is to use your device with SimulANT+ (or any existing ANT+ sensor) it will not work. In fact, SimulANT+ does not even allow the utilization of encrypted channels.
Can anyone please tel me ,is there any possibility to check in which mode(i.e. central or peripheral mode), the BLE is operating? If so on what basis can we find out. I am using BCM20702. It says it supports both modes. But is there a way in which we can find out as to which mode is the device working in?
Regards,
Sathya
If you are advertising, you're a Peripheral. If you are scanning and initiating connections, you're a Central. It's as simple as that.
We've got two WinCE devices that need to talk to each other, they don't have WiFi or Bluetooth so I think a wired USB connection is our best chance. I've been reading up on using ActiveSync and serial over USB, but all the articles are geared towards talking between a WinCE device to a full Windows box, never between two WinCE devices.
If we can get ActiveSync working, that's fine, the other option is just to open COM ports on both sides and write our own communications protocol.
Given the project timelines, writing any sort of device driver isn't an option, this needs to be something that is built in to WinCE.
We are building WinCE for both devices, so I can make any modifications necessary at that level.
Is there a way to get these two guys talking to each other?
If you can't write your own driver then your fastest route is probably to get a USB to serial converter for both devices and then connect them via serial.
Obviously, you'll need to choose one that has support for Windows Mobile. I think FTDI based adapters should work.
Once that's working you just use the built-in serial API to read and write data.
I'm not sure if each hardware type (display screen, USB, printer, etc) has to follow a unified standard in order to communicate with the CPU. For example, the bits transmitted back and forth between a display screen interface and the CPU are interpreted by the CPU as a specific command, and this interpretation is also correct (for the same bits) even if another display screen is used (from another manufacturer).
If this is not true, how BIOS is supposed to communicate with hundreds of different hardware devices with varying methods of interpreting bits going back and forth from the device interface to the CPU?
I find the standardization notion to be much more practical.
The BIOS itself actually only needs to understand a limited set of hardware required to boot the CPU. It does not need to understand "hundreds" of devices. For example, the BIOS has no idea what a USB printer is.
In general, the BIOS only understands the following devices:
The CPU/Chipset "core" hardware - e.g. the DDR3 memory controller
Basic PCI/PCI Express initialization - nothing device-specific
The video controller - just enough code for basic initialization, typically provided by an Option ROM
The SATA controller - as long as it is IDE/ACHI compatible.
The USB controller - possibly just USB 2.0
Standard USB storage devices
Standard USB keyboard/mouse devices
Ethernet controller - typically provided by an Option ROM
Any other device is ignored by the BIOS, unless the vendor included an Option ROM on the board. (You typically see this on SAS/SCSI controllers or Ethernet cards.)
Note most of the devices listed above conform to a standard specification, so they are software compatible regardless of who made it. For example, a USB 2.0 controller should comply with the EHCI spec, it would be compatible across all BIOSes. SATA controllers should follow the AHCI spec.
Once the Operating System loads, it takes over from the BIOS and loads its own drivers to interface with the hardware.
There is specific way(i.e. protocol) for each hardware to communicate with CPU. Maybe we can regard it as "device specification". To communicate with hundreds of different hardware devices BIOS should implement corresponding protocols within it. Thus we can say BIOS is actually a "collection" of specifications.
Whenever new spec is announced, BIOS should be modified to support it, or BIOS does not identify the corresponding device,not to speak of configuring it !
There is a GPS device which can send data to IP:Port. I have a website hosted on IP 1.2.3.4
Can I send GPS data from the device to that website? 1.2.3.4:8080? How I will retrieve the data?
This is the device
http://cgi.ebay.com/GSM-GPRS-GPS-Vehicle-Car-Tracking-System-Tracker-Device-/270683202099?pt=AU_Car_Parts_Accessories&hash=item3f05f9e233
Maybe this should be a comment...
To be honest we can't answer that question the device will most likely use its own data format(s) so the service that receives from it will have to implement those. Additionally the device might not support web protocols, it could use raw TCP sockets for example, so you may have to implement a listener service that adheres to those protocols. In fact it looks like the device uses GSM (a mobile telephony standard), so using a web site to receive the data is definately off the cards unless you have a GSM proxy service sitting between the device and the web server.
Assuming that you are allowed to implement your own service it follows that the documentation will include the necessary details and if you are lucky a full SDK that you can use.