I have a software written by c++, the functionality of this software is to connect to OMNIKEY smart card, and read/write some data, I'm using a following code for read:
m_Errorcode = SCard3WBPReadData(m_Handle, length, m_Data, m_ulOffset);
This was right an no problem there, but after the OmniKey company changed the chip from x-chip to AVIATOR under new product (HID Global OMNIKEY Smart Card Reader), my code stopped and failed to read a data by preceding code.
I have read a lot and I think the problem can be solved by changing a voltage sequence as described at (page 13) in developer guide
https://www.hidglobal.com/doclib/files/resource_files/plt-03635_a.0_-_synchronous-api_software_developer_guide.pdf
There is also chapter in OK SW Dev Guide (Page 17) which suggesting an hexa value (0x1B) to make this change
https://www.hidglobal.com/sites/default/files/resource_files/plt-03099_a.3_-_omnikey_sw_dev_guide.pdf
but until now I can't obtain which is a suitable API function that I must use to pass this suggested Hexa value.
Related
I’m working on Bluetooth mesh network solution and I have requirement to increase range.
I’m using nrf52840 DK and nrf52840 dongles, nrf5SDKforMeshv310.
In Nordic Devzone
I found solution which, enables BLE long range mode in NRF SDK for mesh.
NOTE! I'm aware solution doesn't comply with Bluetooth Mesh standard.
Following changes were applied to nrf5 SDK for Mesh v310:
In advertise.c, set_default_broadcast_configuration() changed radio_mode to use RADIO_MODE_NRF_62K5BIT instead of RADIO_MODE_BLE_1MBIT.
In scanner.c, scanner_config_reset() changed scanner_config_radio_mode_set() to use RADIO_MODE_NRF_62K5BIT instead of RADIO_MODE_BLE_1MBIT.
In radio_config.c, radio_config_config() added the following code at the end:
if (p_config->radio_mode==RADIO_MODE_NRF_62K5BIT ){
NRF_RADIO->PCNF0 |=(
((RADIO_PCNF0_PLEN_LongRange << RADIO_PCNF0_PLEN_Pos) & RADIO_PCNF0_PLEN_Msk) |
((2 << RADIO_PCNF0_CILEN_Pos) & RADIO_PCNF0_CILEN_Msk) |
((3 << RADIO_PCNF0_TERMLEN_Pos) & RADIO_PCNF0_TERMLEN_Msk) );
}
In broadcast.c, time_required_to_send_us() added:
if (radio_mode == RADIO_MODE_NRF_62K5BIT)
{
packet_length_in_bytes +=RADIO_PREAMBLE_LENGTH_LR_EXTRA_BYTES;
}
Defined RADIO_PREAMBLE_LENGTH_LR_EXTRA_BYTES = 9 in same file
Changed 5th element in radio_mode_to_us_per_byte[] from 128 to 64.
NOTE. that the long-range mode is mislabeled. It is called RADIO_MODE_NRF_62K5BIT in the header file but corresponds to the 125kbps BLE long range mode instead.
Unfortunately for relays I’m pushed to use Zephyr to support friend feature and Zephyr is not relaying messages after applying changes to NRF SDK. I did brief investigation on Zephyr side and found that code bits for BLE long range described above for NRF SDK are in place and can be enabled using following Kconfig settings:
CONFIG_BT_AUTO_PHY_UPDATE=y
CONFIG_BT_PHY_UPDATE=y
CONFIG_BT_HCI_MESH_EXT=y
CONFIG_BT_CTLR_PHY=y
CONFIG_BT_CTLR_ADV_EXT=y
CONFIG_BT_CTLR_ADVANCED_FEATURES=y
CONFIG_BT_CTLR_PHY_2M=y
CONFIG_BT_CTLR_PHY_CODED=y
But still I don’t see that messages are being relayed on Zephyr side (using J-Link RTT Viewer). I also tried to increase log level for Bluetooth and Mesh to DEBUG, but I don’t see any signs that messages are malformed or rejected.
May be someone has ideas in which direction I should dig in on Zephyr side?
I need a library for my C++ program.
But the problem, I don't know the name of this data type I want.
I have NPAPI plugin (I know this API is deprecated and removed from modern browsers) which issues to a server
HTTP range requests. Request is asyncronious and the data may arraive in any order with any chunks size.
So I need to track ranges I already have requested from a server.
For example, if initially I requested bytes [10-20] (inclusevely), then I requested [30-40] the data type I need should keep it as two intervals:
[10-20],[30-40]
But if I request [21-29] or even [15-35] it should be merged in one interval:
[10-20],[30-40] + [15-35] = [10-40]
Also I need a substraction when a requested block arrives:
[10-40] - [20-30] = [10-19],[31-40]
(requested - arrived = we're still waiting for)
I had a look at boost::numeric::intervals library but at first glance it is too big for this task (1583 files, 13 Mb of sources after './dist/bin/bcp numeric/interval ~/boost').
Also, GNU ddrescue has some similar arithmetics inside but the code isn't a library there, it coupled too much with the applications specifics.
UPDATE:
Here is what I've found on my way:
A container for integer intervals, such as RangeSet, for C++
https://en.wikipedia.org/wiki/Interval_tree
Boost.ICL
NCBI C++ Toolkit, CIntervalTree
I have some card, wanted to get ATR from it (using method from some SDK).
Implementation looks like this:
unsigned char ATR[128]={0};
int len=33;
int maxlen=33;
ret = sd7816_ATR(0,1,ATR,len,maxlen,1);
first, second and last parameters to sd7816_ATR function should be like that.
The length fields I tried changing to different values, including 0 but no help.
My concern is the ATR string I am sending is empty in the beginning, and I am expecting
something to get written in it after the call finishes (which actually returns success).
But after call ATR is still empty .. What can be going wrong here?
(I want to find out if card is of ISO/IEC 14443 or ISO/IEC 7816 type).
You are trying to receive an ATR for a command specific for a ISO/IEC 7816-3 contact card. In this particular case, that's requested from a (SIM form) SAM card reader. However, you are trying to read out the contactless based reader.
Now contactless cards do not have an ATR. Some cards do have an ATS (i.e. ISO/IEC 14443 Type A cards), but that should be requested by a similar 14443 SELECT command. Some cards, particularly Type B cards, contain an EF.ATR to make up for the lack of (space within the) ATR. Still, an ATR/ATS has only limited functionality for identifying cards.
ISO/IEC 7816 is comprised of several parts: parts 1 to 3 describe contact cards and 4 and higher describe the Application level APDU commands and file structure of processor cards. If your contactless card implements ISO/IEC 7816-4 then you can - in general - also directly use the PCSC interface to send and receive APDU's to/from the card.
In general readers are for contact or contactless only. If you have a reader which contains both contact and contactless operation then in general they will show up as two different readers in the operating system. So in general, if you know the reader, you know if the card is a contact card or contactless card.
SAM slots may not be identified as readers by the operating system - you may only be able to access them using a low level interface. They are mainly used as a secure storage of keys from the terminal/inspection system/interface device or whatever the name is of the system that reads out the card.
Trying to get the temperature of the processor.
Have already tried using WQL (WMI class MSAcpi_ThermalZoneTemperature), but apparently it is not implemented for all the platforms yet. On most of the machines it simply returns every existing error message via HRESULT return value. The temperature itself is not returned.
The idea is to read this temperature directly via the bus port. I have found the library, which gives the functionality of outp and inp functions, and with it managed to start initiate the connection (NTPort), however, the question becomes which port to connect to in order to read the data. The microcontroller is IT8728F. SpeedFan (the application that is able to read the temperature) in its logs says that it reads the data from port 0x290. However, when connecting to it, the data that comes back does not look like temperature (it always returns 29).
So what the next thing that was tried was to read from whatever port, trying to determine if any data that came through looked like temperature. However, from every port some data came through that was either too low or too high to be the real temperature.
int CPU_TEMP;
Outp(INDEX, BANK_SET);
Outp(DATA, Inp(DATA)|0x01);
for(CPU_TEMP=0x0;CPU_TEMP<0x999;CPU_TEMP++)
{
Outp(INDEX, CPU_TEMP);
printf("CPU temp: %iC\n", Inp(DATA));
}
maybe your processor is 29 degrees Celsius and stable. That seems legit for a processor.
Also: is that 0x00000029 or DEC 29? that makes a big difference
Trying to read the sizes of disks that were created in multiple sessions using GetDiskFreeSpaceEx() gives the size of the last session only. How do I read correctly the number and sizes of all sessions in C/C++?
Thanks.
You might want to look at the DeviceIoControl API function. See here for control codes. Here is a code example that retrieves the size of a CD disk. Substitute
CreateFile(TEXT("\\\\.\\PhysicalDrive0")
for e.g.
CreateFile(TEXT("\\\\.\\F:") /* Drive is F: */
if you wish.
Note: The page says that DeviceIoControl can be used to "retrieve information about a floppy disk drive, hard disk drive, tape drive, or CD-ROM drive", but I have also tested it on a DVD, and it seemed to work perfectly. I did not have access to any multisession DVDs to test, so you'll have to test if that works yourself. If it doesn't work, I'd try some of the other control codes, at least IOCTL_DISK_GET_DRIVE_GEOMETRY_EX, IOCTL_DISK_GET_DRIVE_LAYOUT_EX, IOCTL_DISK_GET_LENGTH_INFO and IOCTL_DISK_GET_PARTITION_INFO_EX.
If all fails with DeviceIoControl, you could possibly make use of the Windows Image Mastering API (IMAPI). You'll need v2 of the API (included with Vista & later, can be added to XP & 2003 too, see here: What's new in IMAPIv2) for DVD support. This API is primarily for CD burning, but does perhaps contain some functionality for retrieving disk size, I'd find it weird if it didn't. Particularly, this example seems to be interesting. I do not know if this one works for multisession disks either, but since it can create them, I guess it's likely.
Here are some resources for IMAPI:
MSDN - IMAPI
MSDN - IMAPI interfaces
MSDN - Creating multisession disks with IMAPI (note: example with VB, not C or C++)
Hey I got at least 2 solutions for you:
1) Download dvd+rw-mediainfo.exe from http://fy.chalmers.se/~appro/linux/DVD+RW/tools/win32/, it's a tool that reads info about your disc. Then just make a system call from your app and parse the results. Here's example output:
D:\Downloads>"dvd+rw-mediainfo.exe" f:
INQUIRY: [HL-DT-ST][DVDRAM GT30N ][1.01]
GET [CURRENT] CONFIGURATION:
Mounted Media: 10h, DVD-ROM
Current Write Speed: 1.0x1385=1385KB/s
Write Speed #0: 8.0x1385=11080KB/s
Write Speed #1: 4.0x1385=5540KB/s
Write Speed #2: 2.0x1385=2770KB/s
Write Speed #3: 1.0x1385=1385KB/s
Speed Descriptor#0: 00/2292991 R#8.0x1385=11080KB/s W#8.0x1385=11080KB/s
READ DVD STRUCTURE[#0h]:
Media Book Type: 01h, DVD-ROM book [revision 1]
Legacy lead-out at: 2292992*2KB=4696047616
READ DISC INFORMATION:
Disc status: complete
Number of Sessions: 1
State of Last Session: complete
Number of Tracks: 1
READ TRACK INFORMATION[#1]:
Track State: complete
Track Start Address: 0*2KB
Free Blocks: 0*2KB
Track Size: 2292992*2KB
Last Recorded Address: 2292991*2KB
FABRICATED TOC:
Track#1 : 17#0
Track#AA : 17#2292992
Multi-session Info: #1#0
READ CAPACITY: 2292992*2048=4696047616
2) Investigate mciSendString from [DllImport("winmm.dll", EntryPoint = "mciSendStringA", CharSet = CharSet.Ansi)], I suspect you can send some command and get the desired results.
PS: of course you may download dvd+rw-mediainfo.exe sources from here and investigate further, I am just giving you ideas to think of.
UPDATE
Link to source code updated, thanks #oystein
There are many way to do this since the DVD drives have several interfaces for this due to legacy and backward-compatibility issues.
You could send an IOCTL_SCSI_PASSTHROUGH_DIRECT command to the DVD-drive ( the physicaldevice handle for it). With it you issue a SCSI commands that will be answered by the drive. You can read session information, disk information disk capcity and more.
I believe that dvd+rw-mediainfo.exe issues these.
Unfortunatly, the interface is a bit tricky and obscure, since it is a command within a command. Th passthrough has a byte buffer you will have to fill in yourself with the command structure.
Or you can call IOCTL_CDROM_READ_TOC_EX:
http://www.osronline.com/ddkx/storage/k306_2cs2.htm
I also believe that the exact set of the IOCTL / commands that will work depends on on the drive and its firmaware.
Older drives will not support the newr interfaces and some of the newer drives will not support legacy interfaces.
Thus, some of the libraries & tools might use one or more of these interfaces.
Accseeing the older sessons is all quite messy, really, since most OS will not care about them, only the most recent ones.