everyone. Recently, I was developing a method to access the camera extension unit through windows and send commands through the interface "ksproperty". There was a problem. Commands 0x01-0x19 can be sent normally, but commands 0x20 and above failed, and the error code 0x80070490 was returned. Is this a limitation of windows.
Yes, it is a limitation of usbvideo.sys. https://learn.microsoft.com/en-us/windows-hardware/drivers/stream/device-requirements-for-usb-video-class-extension-units
Related
I am working on a simple web application that sends commands to an HC-06 Bluetooth module using Web Bluetooth API. So far, I have successfully connected the device to the browser and gained access to the server, service, and characteristics. The problem starts when I try to do anything after that point. Reading or writing to the HC-06 throws DOMException: GATT operation not permitted.
I logged characteristic.properties (in the fourth promise chain) and seem to have found the problem. BluetoothCharacteristicProperties is the following object:
{
authenticatedSignedWrites: false
broadcast: false
indicate: false
notify: true
read: false
reliableWrite: false
writableAuxiliaries: false
write: false
writeWithoutResponse: false
}
So, it makes sense that I can not perform any operations on the module. What I don't understand is why the permissions are set to false. I already have a working Python application that perfectly communicates with the same HC-06 - and I can send commands to it through an Android terminal. This leads me to believe there is some misconfiguration I've overlooked in the web app implementation. Is there a way to change these permissions through the Web Bluetooth API? Or perhaps through AT commands to the module itself? Or maybe the API simply won't work with this model? Any help would be appreciated!
Thanks to #nondebug for the help! Turns out there is a lot of distinction between Bluetooth modules. The HC-06 that I'm using for this project is running Bluetooth 2.0, and the Web Bluetooth API requires Bluetooth 4.0 and above. I was able to write some Javascript using the Web Serial API instead, and can make a connection to my device using a desktop browser. Unfortunately, mobile browsers do not seem to support Web Serial API. Time to get started on a native app I guess!
You are writing to the wrong GATT service characteristic.
Notify and read on characteristic 0xFFE1.
Writing on characteristic 0xFFE2.
Got it working: ble on HC-06.
Its a strang chinese clone.
I used Bluetooth LE Explorer.
Installed from the MS Store.
Connect TX and RX together.
Set "Notify" and "Use Windows Notifications" on for characteristic 0xFFE1
Write value (UTF8) for characteristic 0xFFE2
Data you write show-up in the Windows Notification window.
On a test server there are two Samsung 960 Pro SSDs, exactly same maker, model and size. On both I've installed a fresh install of exactly the same OS, OmniOS r15026.
By pressing F8 at POST time, I can access the motherboard BOOT manager, and choose one of the two boot drives. Thus, I know which one the system booted from.
But how can one know programmatically, after boot, which is the boot disk?
It seems that is:
Not possible on Linux,
Not possible on FreeBsd
Possible on macOS.
Does Solaris/illumos offer some introspective hooks to determine which is the boot disk?
Is it possible to programmatically determine which is the boot disk on Solaris/illumos?
A command line tool would be fine too.
Edit 1: Thanks to #andrew-henle, I have come to know command eeprom.
As expected it is available on illumos, but on test server with OmniOS unfortunately it doesn't return much:
root#omnios:~# eeprom
keyboard-layout=US-English
ata-dma-enabled=1
atapi-cd-dma-enabled=1
ttyd-rts-dtr-off=false
ttyd-ignore-cd=true
ttyc-rts-dtr-off=false
ttyc-ignore-cd=true
ttyb-rts-dtr-off=false
ttyb-ignore-cd=true
ttya-rts-dtr-off=false
ttya-ignore-cd=true
ttyd-mode=9600,8,n,1,-
ttyc-mode=9600,8,n,1,-
ttyb-mode=9600,8,n,1,-
ttya-mode=9600,8,n,1,-
lba-access-ok=1
root#omnios:~# eeprom boot-device
boot-device: data not available.
Solution on OmniOS r15026
Thanks to #abarczyk I was able to determine the correct boot disk.
I had to use a slightly different syntax:
root#omnios:~# /usr/sbin/prtconf -v | ggrep -1 bootpath
value='unix'
name='bootpath' type=string items=1
value='/pci#38,0/pci1022,1453#1,1/pci144d,a801#0/blkdev#w0025385971B16535,0:b
With /usr/sbin/format, I was able to see entry corresponds to
16. c1t0025385971B16535d0 <Samsung-SSD 960 PRO 512GB-2B6QCXP7-476.94GB>
/pci#38,0/pci1022,1453#1,1/pci144d,a801#0/blkdev#w0025385971B16535,0
which is correct, as that is the disk I manually selected in BIOS.
Thank you very much to #abarczyk and #andrew-henle to consider this and offer instructive help.
The best way to find the device from which the systems is booted is to check prtconf -vp output:
# /usr/sbin/prtconf -vp | grep bootpath
bootpath: '/pci#0,600000/pci#0/scsi#1/disk#0,0:a'
On my Solaris 11.4 Beta system, there is a very useful command called devprop which helps answer your question:
$ devprop -s bootpath
/pci#0,0/pci1849,8c02#1f,2/disk#1,0:b
then you just have to look through the output of format to see what that translates to. On my system, that is
9. c2t1d0 <ATA-ST1000DM003-1CH1-CC47-931.51GB>
/pci#0,0/pci1849,8c02#1f,2/disk#1,0
Use the eeprom command.
Per the eeprom man page:
Description
eeprom displays or changes the values of parameters in the EEPROM.
It processes parameters in the order given. When processing a
parameter accompanied by a value, eeprom makes the indicated
alteration to the EEPROM; otherwise, it displays the parameter's
value. When given no parameter specifiers, eeprom displays the values
of all EEPROM parameters. A '−' (hyphen) flag specifies that
parameters and values are to be read from the standard input (one
parameter or parameter=value per line).
Only the super-user may alter the EEPROM contents.
eeprom verifies the EEPROM checksums and complains if they are
incorrect.
platform-name is the name of the platform implementation and can be
found using the –i option of uname(1).
SPARC
SPARC based systems implement firmware password protection with
eeprom, using the security-mode, security-password and
security-#badlogins properties.
x86
EEPROM storage is simulated using a file residing in the
platform-specific boot area. The /boot/solaris/bootenv.rc file
simulates EEPROM storage.
Because x86 based systems typically implement password protection in
the system BIOS, there is no support for password protection in the
eeprom program. While it is possible to set the security-mode,
security-password and security-#badlogins properties on x86 based
systems, these properties have no special meaning or behavior on x86
based systems.
I came across the following error described below, how can I rectify this sort of error and why does this error is generated?
QIODEVICE::write:device not open
( the com port are also not visible in device manager)
Is this some sort of system error ?
If you have using just Qt then use QSerialPort otherwise you can use windows API createfile(), readfile() ,writefile() in Windows Platform.
You can take other information in:
http://support.microsoft.com/KB/115831
or this post in Stackoverflow:
Open a COM port in C++ with number higher that 9
I wanna write a remote console, working like a telnet server. User is able to use telnet to log into the server, then write some commands to do some works.
A good example for this is the console of router os. What I'm confusing right now is, I can accept user's input, do someting then print some texts back, but I wanna use ncurses to make the console has more features(such as "cmd auto-complete", syntax color...), so how can I do that? Because the console is in user side, if the server calls ncurses APIs it'll just change stuffs on server...
Maybe this is a stupid question but I'm really newbie on this. Any suggestions are appreciated.
This is more difficult than you might think.
You need to understand how terminals work - they use special control sequences for e.g. moving the cursor or color output. This is described by a terminfo file which is terminal-specific. Ncurses translates API calls (e.g. move cursor to a certain position) to such control sequences using terminfo.
Since the terminal (nowadays xterm, gnome-terminal, screen, tmux, etc) is on the client side, you have to pass the type of terminal from the client to the server. That's why e.g. ssh passes this information from the ssh client to the server (try echo $TERM in your ssh session - it might be 'linux' if you are logged in via the console, or 'xterm', if you are using X and an xterm). Also, you better have the respective terminfo available on the server.
Another piece of the puzzle is pseudo terminals. As nowadays relatively few people use serial terminals, their semantics are emulated so that applications and libraries (e.g. curses and its friends) originally developed for serial consoles keep working. This is achieved via pseudo terminals - these are like pipes, a master and a slave device communicates, anything written on one side comes out on the other side. For a login process, getty, for example, can just use one side of a pty device and think it's a serial line - your server program must handle the other side of the pty, sending everything it gets from the pty to your client via the network.
Terminal emulators also use ptys, type tty into your terminal, and you'll get something like /dev/pts/9 if you're using a terminal emulator. On the other side of the pty it's usually your shell, communicating with your terminal emulator via the pty.
Your client program can more or less just use standard input and standard output. If your terminal information is correct, the rest will be handled by your terminal emulator, just pass anything you receive from your server program to stdout, and send anything you read from stdin to your server program.
Hopefully I haven't left out any important detail. Good luck!
It is possible to have ncurses operate on streams other than stdin and stdout. Call newterm() before initscr() to set the input and output file handles for ncurses.
But you will need to know what sort of terminal is on the remote end of the connection (ssh and telnet both have mechanisms for communicating this to the server) and you will also want a fall back to a non-ncurses interface in case the remote end is not a supported terminal type (or if you can't determine the terminal type).
I need to send commands through Serial Port to control a electronic device. According the datasheet of this device, the command structure is as follows: Prefix Command Carriage Return. There are some commands, e.g. GOCW_BY1, STATUSRQ, etc.
The program will be developed in C++/CLI. After, I create the SerialPort objectand I set the port parameters, I send commands using the write("String") method of SerialPort class. However, I haven't still realized what kind of string I must set on write method.
Moreover, I don't know the meaning of prefix. Could you help me?
In C++/CLI, I recommend against using the .NET System::IO::Ports::SerialPort class. C++/CLI gives you convenient access to the Win32 API, which are far more powerful (and IMO easier to use) than the .NET API.
See for example this question about accessing serial ports from C++