minor: fix comment typos (#1646)
This commit is contained in:
parent
dab8825b8a
commit
2b30da35f0
18 changed files with 25 additions and 25 deletions
|
@ -6,7 +6,7 @@
|
|||
#
|
||||
# Boolean options can be true/false, yes/no, on/off, enable/disable, or 1/0
|
||||
#
|
||||
# All options will be applied in the order given, overwritting previous values
|
||||
# All options will be applied in the order given, overwriting previous values
|
||||
#
|
||||
# Config files can be nested/stacked (use multiple -c and config_file = ).
|
||||
#
|
||||
|
@ -52,7 +52,7 @@ gain 0
|
|||
|
||||
# as command line option:
|
||||
# [-f <frequency>] [-f...] Receive frequency(s) (default: 433920000 Hz)
|
||||
# default is "433.92M", other resonable values are 315M, 345M, 915M and 868M
|
||||
# default is "433.92M", other reasonable values are 315M, 345M, 915M and 868M
|
||||
frequency 433.92M
|
||||
|
||||
# as command line option:
|
||||
|
|
|
@ -348,7 +348,7 @@ If you are developing or testing a decoder you can skip the device input or samp
|
|||
|
||||
### File names
|
||||
|
||||
Samples recorded using the `-S` option will automaticly be given filenames with some meta-data.
|
||||
Samples recorded using the `-S` option will automatically be given filenames with some meta-data.
|
||||
The signals will be stored individually in files named `g<NNN>_<FFF>M_<RRR>k.cu8` :
|
||||
|
||||
| Parameter | Description
|
||||
|
|
|
@ -25,7 +25,7 @@ rtl_433 \- Generic RF data receiver and decoder for ISM band devices using RTL-S
|
|||
This manual page documents briefly the \fBrtl_433\fP command.
|
||||
.sp
|
||||
\fBrtl_433\fP is a generic data receiver, mainly for the 433.92 MHz, 868 MHz (SRD),
|
||||
315 MHz, and 915 MHz ISM bands. It works with RTL\-SDR and/or SoapySDR. Activly tested
|
||||
315 MHz, and 915 MHz ISM bands. It works with RTL\-SDR and/or SoapySDR. Actively tested
|
||||
and supported are Realtek RTL2832 based DVB dongles (using RTL\-SDR) and LimeSDR
|
||||
(LimeSDR USB and LimeSDR mini engineering samples kindly provided by MyriadRf),
|
||||
PlutoSDR, HackRF One (using SoapySDR drivers), as well as SoapyRemote.
|
||||
|
|
|
@ -64,7 +64,7 @@
|
|||
* and the payload may be interpreted.
|
||||
*
|
||||
* Note that if the transmitter's ID isn't known, the code can't easily determine if messages other than an
|
||||
* ID payload are good or bad, and can't intepret their data correctly. However, if the "auto" mode is enabled,
|
||||
* ID payload are good or bad, and can't interpret their data correctly. However, if the "auto" mode is enabled,
|
||||
* the system can try to learn the transmitter's ID by various methods. (See USAGE HINTS below)
|
||||
*
|
||||
* For the power message (1), the offset payload gives the number of milliseconds gap between impulses for the most
|
||||
|
|
|
@ -164,7 +164,7 @@ static int dsc_callback(r_device *decoder, bitbuffer_t *bitbuffer)
|
|||
}
|
||||
|
||||
status = bytes[0];
|
||||
//subtype = bytes[1] >> 4; // @todo needed for detecing keyfob
|
||||
//subtype = bytes[1] >> 4; // @todo needed for detecting keyfob
|
||||
esn = (bytes[1] << 16) | (bytes[2] << 8) | bytes[3];
|
||||
crc = bytes[4];
|
||||
|
||||
|
|
|
@ -72,7 +72,7 @@ Removing the first 1 or 2 bits gives a prefix of 55a8aaaaaa2dd4, the leading bit
|
|||
The next bytes of 5231 5c6a 7700 are likely a serial number (id).
|
||||
|
||||
Then we have messages with 414b or 565a or 5053 which likely is a message type.
|
||||
On 414b the two byte (little endian) power value follows. For the other types it is unknonwn, maybe kWh or state.
|
||||
On 414b the two byte (little endian) power value follows. For the other types it is unknown, maybe kWh or state.
|
||||
Lastly there is a fixed 53 (status? stop?) and a checksum byte.
|
||||
|
||||
Interesting to note that 414b, 565a, and 53 are "AK", "VZ", and "S" which might not be a coincidence.
|
||||
|
|
|
@ -116,7 +116,7 @@ static int gt_tmbbq05_decode(r_device *decoder, bitbuffer_t *bitbuffer)
|
|||
return DECODE_FAIL_MIC;
|
||||
}
|
||||
|
||||
// temperature: concat the upper bits to the lower bits and substract the fixed offset 90
|
||||
// temperature: concat the upper bits to the lower bits and subtract the fixed offset 90
|
||||
int tempf = (((b[3] & 0xc0) << 2) | b[1]) - 90;
|
||||
|
||||
// device id: concat the two bytes
|
||||
|
|
|
@ -33,7 +33,7 @@ The data is sent using CPFSK modulation. It requires PD_MIN_PULSE_SAMPLES in
|
|||
pulse_detect.h to be lowered to 5 to be able to demodulate at 250kS/s. The
|
||||
preamble is optimally 4 bytes of 0XAA. Then the sync word 0xD201. Here only
|
||||
the last 2 bytes of the 0xAA preamble is checked, as the first ones seems
|
||||
to be corrupted quite often. There are plenty of integrety checks made on
|
||||
to be corrupted quite often. There are plenty of integrity checks made on
|
||||
the demodulated package which makes this compromise OK.
|
||||
|
||||
Packet structure according to: https://github.com/strigeus/sparsnas_decoder
|
||||
|
@ -54,8 +54,8 @@ Packet structure according to: https://github.com/strigeus/sparsnas_decoder
|
|||
Example packet: 0x11a15f070ea2dfefe6d5fdd20547e6340ae7be61
|
||||
|
||||
|
||||
The packet's integrety can be checked with the 16b CRC at the end of the packet.
|
||||
There are also several other ways to check the integrety of the package.
|
||||
The packet's integrity can be checked with the 16b CRC at the end of the packet.
|
||||
There are also several other ways to check the integrity of the package.
|
||||
- (preamble)
|
||||
- CRC
|
||||
- The decrypted sensor ID
|
||||
|
|
|
@ -489,12 +489,12 @@ static char *output_fields[] = {
|
|||
"from_id",
|
||||
"to_id",
|
||||
"msg_type", // packet type at int
|
||||
"msg_type_str", // packet type as formated string
|
||||
"msg_type_str", // packet type as formatted string
|
||||
// "command",
|
||||
"extended", // 0= short pkt, 1=extended pkt
|
||||
"hops_max", // almost always 3
|
||||
"hops_left", // remaining hops
|
||||
"formatted", // entire packet as a formated string with hex
|
||||
"formatted", // entire packet as a formatted string with hex
|
||||
"mic", // remove if not applicable
|
||||
"payload", // packet as a hex string
|
||||
"cmd_dat", // array of int containing command + data
|
||||
|
|
|
@ -66,7 +66,7 @@ Packet length is 264 bits according to inspectrum broken down as follows:
|
|||
- trailer: 32 bytes (0xd2d2d200)
|
||||
|
||||
The sensor generates a packet every 'n' seconds but only transmits if one or
|
||||
more of the following conditions are satified:
|
||||
more of the following conditions are satisfied:
|
||||
|
||||
- temp changes +/- 0.8 degrees C
|
||||
- humidity changes +/- 1%
|
||||
|
|
|
@ -77,7 +77,7 @@ static int lacrosse_th_decode(r_device *decoder, bitbuffer_t *bitbuffer)
|
|||
// bit length is specified as 104us for the TH3 (~256 bits per packet)
|
||||
// but the TH2 bit length is actually 107us leading the bitbuffer to
|
||||
// report the packet length as ~286 bits long. We'll use this fact
|
||||
// to indentify which of the two models actually sent the data.
|
||||
// to identify which of the two models actually sent the data.
|
||||
if (bitbuffer->bits_per_row[0] < 156) {
|
||||
if (decoder->verbose) {
|
||||
fprintf(stderr, "%s: Packet too short: %d bits\n", __func__, bitbuffer->bits_per_row[0]);
|
||||
|
|
|
@ -26,7 +26,7 @@ Message Layout:
|
|||
P P S A D..D X C
|
||||
|
||||
- Preamble: 10x bit "0", bit "1"
|
||||
- Sensor Type: Value 0..9 determing the sensor type
|
||||
- Sensor Type: Value 0..9 determining the sensor type
|
||||
- 0 = WS7000-27/28 Thermo sensor (interval 177s - Addr * 0.5s)
|
||||
- 1 = WS7000-22/25 Thermo/Humidity sensor (interval 177s - Addr * 0.5s)
|
||||
- 2 = WS7000-16 Rain sensor (interval 173s - Addr * 0.5s)
|
||||
|
|
|
@ -15,7 +15,7 @@
|
|||
Keep the Doxygen (slash-star-star) comment above to document the file and copyright.
|
||||
|
||||
Keep the Doxygen (slash-star-star) comment below to describe the decoder.
|
||||
See http://www.doxygen.nl/manual/markdown.html for the formating options.
|
||||
See http://www.doxygen.nl/manual/markdown.html for the formatting options.
|
||||
|
||||
Remove all other multiline (slash-star) comments.
|
||||
Use single-line (slash-slash) comments to annontate important lines if needed.
|
||||
|
|
|
@ -117,7 +117,7 @@ static unsigned short int cm180_power(uint8_t const *msg)
|
|||
{
|
||||
unsigned short int val = 0;
|
||||
val = (msg[4] << 8) | (msg[3] & 0xF0);
|
||||
// tested accross situations varying from 700 watt to more than 8000 watt to
|
||||
// tested across situations varying from 700 watt to more than 8000 watt to
|
||||
// get same value as showed in physical CM180 panel (exactly equals to 1+1/160)
|
||||
val *= 1.00625;
|
||||
return val;
|
||||
|
|
|
@ -42,7 +42,7 @@ Binary | Trinary
|
|||
|
||||
000100110111011100110001 -> 0001 0011 0111 0111 0011 0001 -> 1 11 111 111 11 1 -> [0, 1,2, 2, 1, 0]
|
||||
|
||||
The pattens `1 1 1 1` or `0 0 0 0` should never happen
|
||||
The patterns `1 1 1 1` or `0 0 0 0` should never happen
|
||||
|
||||
*/
|
||||
|
||||
|
@ -263,7 +263,7 @@ static int secplus_v1_callback(r_device *decoder, bitbuffer_t *bitbuffer)
|
|||
return -1; // should never get here
|
||||
}
|
||||
|
||||
// if we are here we have recived both packets, stored in result_1 & result_2
|
||||
// if we are here we have received both packets, stored in result_1 & result_2
|
||||
// we now generate values for rolling_temp & fixed
|
||||
// using the trinary data stored in result_1 & result_2
|
||||
|
||||
|
|
|
@ -291,7 +291,7 @@ static int secplus_v2_callback(r_device *decoder, bitbuffer_t *bitbuffer)
|
|||
}
|
||||
|
||||
// valid = 0X00XXXX
|
||||
// 1st 3rs and 4th bits should alway be 0
|
||||
// 1st 3rs and 4th bits should always be 0
|
||||
if (bits.bb[0][0] & 0xB0) {
|
||||
if (decoder->verbose)
|
||||
fprintf(stderr, "%s: DECODE_FAIL_SANITY\n", __func__);
|
||||
|
@ -310,7 +310,7 @@ static int secplus_v2_callback(r_device *decoder, bitbuffer_t *bitbuffer)
|
|||
_decode_v2_half(&bits, rolling_1, &fixed_1, decoder->verbose);
|
||||
}
|
||||
|
||||
// break if we've recived both halfs
|
||||
// break if we've received both halfs
|
||||
if (fixed_1.bits_per_row[0] > 1 && fixed_2.bits_per_row[0] > 1) {
|
||||
break;
|
||||
}
|
||||
|
|
|
@ -6798,7 +6798,7 @@ static void mg_http_multipart_begin(struct mg_connection *nc,
|
|||
|
||||
ct = mg_get_http_header(hm, "Content-Type");
|
||||
if (ct == NULL) {
|
||||
/* We need more data - or it isn't multipart mesage */
|
||||
/* We need more data - or it isn't multipart message */
|
||||
goto exit_mp;
|
||||
}
|
||||
|
||||
|
@ -11039,7 +11039,7 @@ static struct mg_str mg_mqtt_next_topic_component(struct mg_str *topic) {
|
|||
return res;
|
||||
}
|
||||
|
||||
/* Refernce: https://mosquitto.org/man/mqtt-7.html */
|
||||
/* Reference: https://mosquitto.org/man/mqtt-7.html */
|
||||
int mg_mqtt_match_topic_expression(struct mg_str exp, struct mg_str topic) {
|
||||
struct mg_str ec, tc;
|
||||
if (exp.len == 0) return 0;
|
||||
|
|
|
@ -228,7 +228,7 @@ data_t *pulse_data_print_data(pulse_data_t *data)
|
|||
|
||||
/// Internal state data for pulse_pulse_package()
|
||||
struct pulse_detect {
|
||||
int use_mag_est; ///< Wether the envelope data is an amplitude or magnitude.
|
||||
int use_mag_est; ///< Whether the envelope data is an amplitude or magnitude.
|
||||
int ook_fixed_high_level; ///< Manual detection level override, 0 = auto.
|
||||
int ook_min_high_level; ///< Minimum estimate of high level (-12 dB: 1000 amp, 4000 mag).
|
||||
int ook_high_low_ratio; ///< Default ratio between high and low (noise) level (9 dB: x8 amp, 11 dB: x3.6 mag).
|
||||
|
|
Loading…
Add table
Reference in a new issue