I came accros this kind of line in a proprietary use of the AT commands:
AT*REF=1,290717696<LF>
It is a proprietary command as it is used in a protocol to control a robot.
According to what I read on Wikipedia and other sources, AT command extensions should use "\" or "%". There is no mention of "*".
So what does * define?
There are more than two different characters in use by various manufacturers when implementing the first character of a proprietary AT command. Some that I've seen:
! # # $ % ^ * _
The manufacturer of your device may have chosen '*' for commands that have similar functionality, or they may have chosen to implement ALL of their proprietary AT commands with '*' as the first character.
There are many AT command references available online in PDF format from many different manufacturers. Perhaps the manufacturer of your device makes this information available as well.
Related
The Microsoft documentation for the WAVEOUTCAPS struct lists a number of formats that an audio device can support:
I do not see any 24-bit variables listed here, although through I have confirmed my sound card is capable of opening a 24-bit output with a call to WaveOutOpen (and playing 24bit audio files through that output).
I'm guessing that Microsoft defined additional variables somewhere for 18/20/24/32/48/64 bit output, but I can't find them. I tried searching on the net and nothing came up, and I tried using Visual Studio to search for variables in my current name space that start with "WAVE_FORMAT_" but did not find any additionally defined formats that way.
Is it possible to check for 4/18/20/24/32/48/64 bit output availability on Windows using the function WaveOutGetDevCap(), or any similar function? If so, how?
waveOutXxx is legacy API you, generally speaking, should not be used nowadays. This API is an emulation layer on top of real audio API and does not have to support 24-bit scenarios which did not exist at the time of waveOutXxx. There are no specific new constants defined for newer formats and there are so many of them that there cannot be a separate bit for every one.
You can compose a WAVEFORMATEX structure that describes your high bitness format (you would typically use WAVEFORMATEXTENSIBLE variant of it) and check it against waveOutOpen function.
Or, rather, use WASAPI and IAudioClient::Initialize, see Rendering a Stream for details and the way WAVEFORMATEX structure is used there.
Scenario:
I have an usb-RFID reader
attaching it to notebook it works as an newly attached USB keyboard, e.g. without needing to install any drivers
when touching the reader with RFID tag
it enters into my current window (for example terminal/shell) the RFID number (like 0009339384\n) - e.g. it even sends the \n.
so, it works exactly as if I had typed the numbers in my notebook's keyboard
The questions are:
is it possible read the RFID reader directly without some kernel-level drivers, e.g. something like cat /dev/keyboard1 ...
in other words, how can I determine from which "keyboard" the characters are coming?
using OS X, but would be nice to know the solution for Linux too.
Moreover, I want attach two readers - so I definitely need to clearly differentiate between the two readers. And I want use the rfid-reader in a bash (perl) script, so I'm definitely looking for a solution without compiling some "drivers"... It is possible?
The OS X identifies it as:
SYC ID&IC USB Reader:
Product ID: 0x0035
Vendor ID: 0xffff
Version: 1.00
Serial Number: 08FF20140315
Speed: Up to 1.5 Mb/sec
Manufacturer: Sycreader RFID Technology Co., Ltd
Location ID: 0x14100000 / 18
Current Available (mA): 500
Current Required (mA): 100
Extra Operating Current (mA): 0
EDIT Okay, looks like in Linux it can be done - just found
this https://unix.stackexchange.com/questions/72483/how-to-distinguish-input-from-different-keyboards
also Accessing multiple keyboards input by C++ (or python) in linux
For OS X - exact duplicate on unix: https://unix.stackexchange.com/questions/228413/route-keyboard-through-only-dev-ttys000-on-mac-os-x - unfortunately, closed without any answer :(
Ok, so - easily solvable in Linux. As in edits in the question - here are already many similar questions like this.
The solution is: reading the particular /dev/input/eventN device(s).
In my case, me using the Linux::Input perl module. Works perfectly.
It is pointless adding code here, the package comes with the evtest.pl - so anyone could easily check how it works.
Still need solve one issue - e.g. even when reading the device and nicely getting all events from the rfid reader (4 events for one number), the rfid-code still is inserted into the active window, like it coming from a keyboard. (This will be an another question).
For OS X i haven't an easy solution yet, but now focusing for the Linux variant. :)
There is one thing that might help you solve this problem without resorting to programming in C. It is called multiseat. I didn't do it myself I just know it exists. In general it is a way how multiple people can work on same computer at the same time just using multiple keyboards, mice and monitors. It is not exactly what you are looking for but there might be possible way.
Here is a quote from this article:
ISO 9660 is not a complex file system, but has a few quirks that are
worth remembering. It seems that some operating systems also create
non-compliant CDs, so beware! The main example of this is the
character set that is available for file names. Strictly,filenames may
only consist of uppercase letters A-Z, digits, dots, and underscores.
Further there is a semicolon which separates the visible file name
from its version number suffix. Many operating systems also allow
lower case letters and other characters. Linux's VFS displays lower
case filenames to the user despite the CD contents actually containing
upper case characters.
So my question is, how does Linux know which letters are supposed to be uppercase and which letters are supposed to be lowercase, when on the CD they are all uppercase?
The ISO9660 filesystem has only supported filenames in the 8.3 uppercase format.
Some technologies have been designed over the years to extend the ISO9660 filesystem with features like long filenames, lowercase letters, and file permissions. The Joliet filesystem is the Windows solution, while Rock Ridge is one that works with Linux. In essence they store the original filename, with proper case, in a lookup table that is recorded in the removable media. More information in the Wikipedia article for ISO9660.
What is the pci.ids file? Where can I find it? What is the purpose of this file?
I'm new in Linux programming and stumbled over this file.
This is a repository of known ID's used in PCI devices: ID's of vendors, devices, subsystems and device classes. It is used in various programs to display full human-readable names instead of cryptic numeric codes.
The location of this file is at: /usr/share/hwdata/pci.ids
Read more
I have a quite big problem, where I can't find any help around in the web:
I moved a page from a website from OSX to Linux (both systems are running in de_DE.UTF-8) and run in an quite unknown problem:
Some of the files were not found anymore, but obviously existed on the harddrive with (visibly) the same name. All those files contained german umlauts.
I took one sample image, copied the original request-uri from the webpage and called it directly - same error. After rewriting the file-name it worked. And yes, I did not mistype it!
This surprised me and I took a look into the apache-log where I found these entries:
192.168.56.10 - - [27/Aug/2012:20:03:21 +0200] "GET /images/Sch%C3%B6ne-Lau-150x150.jpg HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/537.1"
192.168.56.10 - - [27/Aug/2012:20:03:57 +0200] "GET /images/Scho%CC%88ne-Lau-150x150.jpg HTTP/1.1" 404 4205 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/537.1"
That was something for me to investigate ... Here's what I found in the UTF8 chartable http://www.utf8-chartable.de/:
ö c3 b6 LATIN SMALL LETTER O WITH DIAERESIS
¨ cc 88 COMBINING DIAERESIS
I think you've already heard of dead-keys: http://en.wikipedia.org/wiki/Dead_key If not, read the article. It's quite interesting ;)
Does that mean, that OSX saves all diacritics separate to the letter? Does that really mean, that OSX saves the character ö as o and ¨ instead of using the real character that results of the combination?
If yes, do you know of a good script that I could use to rename these files? This won't be the first page I move from OSX to Linux ...
It's not quite the same thing as dead keys, but it's related. As you've worked out, U+00F6 and U+006F followed by U+0308 have the same visual result.
There are in fact Unicode rules in knowing to treat them the same, which is based on decompositions. There's a decomposition table in the character database, that tells us that U+00F6 canonically decomposes to U+006F followed by U+0308.
As well as canonical decomposition, there are compatibility decompositions. These lose some information, for example ² ends up being decomposed to 2. This is clearly a destructive change, but it is useful for searching when you want to be a bit fuzzy (how google knows a search for fiſh should return results about fish).
If there are more than one combining character after a non-combining character, then we can re-order them as long as we don't re-order those of the same class. This becomes clear when we consider that it doesn't matter whether we put a cedilla on something and then an acute accent, or an acute and then a cedilla, but if we put both an acute and an umlaut on a letter it clearly matters what way around they go.
From this, we have 4 normalisation forms. Put strings into an appropriate normalisation form before doing comparisons, and you don't get tripped up.
NFD: Break everything apart by canonically decomposing it as much as possible. Reorder combining characters in order of their combining class, but keep any with the same class in the same order relative to each other.
NFC: First put everything into NFD. Then continually look at the combining characters in order, if there isn't an earlier one of the same class. If there is an equivalent single character, then replace them, and re-do the scan looking to compose further.
NFKD: Like NFD, but using compatibility decomposition (damaging change, but useful for comparisons as explained above).
NFD: Do NFKD, then re-combine canonical only as per NFC.
There are also some re-combinations banned from use in NFC so that text that was valid NFC in one version of Unicode doesn't cease to be NFC if Unicode has more characters added to it.
Of NFD and NFC, NFC is clearly the more concise. It's not the most concise possible, but it is one that is very concise and can be tested for and/or created in a very efficient streaming manner.
Mac OSX uses NFD for file names. Because they're weirdos. (Okay, there are better arguments than that, they just didn't convince me!)
The Web Character Model uses NFC.* As such, you should use NFC on web stuff as much as possible. There can though be security considerations in blindly converting stuff to NFC. But if it starts from you, it should start in NFC.
Any programming language that deals with text should have a nice way of normlising text into any of these forms. If yours doesn't complain (or if yours is open source, contribute!).
See http://unicode.org/faq/normalization.html for more, or http://unicode.org/reports/tr15/ for the full gory details.
*For extra fun, if you inserted something beginning with a combining long solidus overlay (U+0338) at the start of an XML or HTML element's content, it would turn the > of the tag into ≯, turning well-formed XML into gibberish. For this reason the web character model insists that each entity must itself be NFC and not start with a combining character.
Thanks, Jon Hanna for much background-information here! This was important to get the full answer: a way to convert from the one to the other normalisation form.
As my changes are in the filesystem (because of file-upload) that is linked in the database, I now have to update my database-dump. The files got already renamed during the move (maybe by the FTP-Client ...)
Command line tools to convert charsets on Linux are:
iconv - converting the content of a stream (maybe a file)
convmv - converting the filenames in a directory
The charset utf-8-mac (as described in http://loopkid.net/articles/2011/03/19/groking-hfs-character-encoding), I could use in iconv, seems to exist just on OSX systems and so I have to move my sql-dump to my mac, convert it and move it back. Another option would be to rename the files back using convmv to NFD, but this would more hinder than help in the future, I think.
The tool convmv has a build-in (os-independent) option to enforcing NFC- or NFD-compatible filenames: http://www.j3e.de/linux/convmv/man/
PHP itself (the language my system - Wordpress is based on) supports a compatibility-layer here:
In PHP, how do I deal with the difference in encoded filenames on HFS+ vs. elsewhere? After I fixed this issue for me, I will go and write some tests and may also write a bug-report to Wordpress and other systems I work with ;)
Linux distros treat filenames as binary strings, meaning no encoding is assumed - though the graphical shell (Gnome, KDE, etc) might make some assumptions based on environment variables, locale, etc.
OS-X on the other hand requires or enforces (I forget which) their own version of UTF-8 with Unicode normalization to expand all diacritics into combining characters.
On Linux when people do use Unicode in filenames they tend to prefer UTF-8 with precomposed characters when it comes to diacritics.