Averaging using Group by and Distinct in sql - group-by

This is a bit convoluted but I will try to make it not so. Below is a snippet of the data and the intended result below it. For every combination of state, area, indcode, and ownership I want to calculate an average. My knowledge of AVG in SQL would average the entire column not just specific values.
state areatype area period indcode ownership sites employment
32 05 000001 01 102800 12 25 256
32 05 000001 01 102900 13 6 26
32 05 000003 01 102800 12 774 1874
.
.
32 05 000001 02 102800 12 27 239
32 05 000001 03 102800 12 28 241
32 05 000001 04 102800 12 29 248
Intended result
32 05 000001 00 102800 12 27 246
Would the following code do this or be even close?
Select avg(employment, sites)
From Select (Distinct(state, area, indcode, ownership) from dbo.tablename;

select
[state], areatype, area, '00' [period], indcode, ownership,
avg(sites) sites, avg(employment) employment
from dbo.tablename
group by [state], areatype, area, indcode, ownership;
Got this mostly by trial and error and help from another site. Not really sure why it works but its close enough.

Related

BLE Communication Protocol T1S (Smart Band) Get Data

I want to communicate my android app to this smart band (T1S), I've already paired it, but I don't know how to extract data from it, such as temperature, etc.
I got the characteristics and services from it:
{"name":"T1S","id":"F4:C3:33:99:21:5D","advertising":{},"rssi":-78,"services":["1801","1800","6e400001-b5a3-f393-e0a9-e50e24dcca9e","1812","fee7"],"characteristics":[{"service":"1801","characteristic":"2a05","properties":["Broadcast","Read","Write","Notify","Indicate","AuthenticateSignedWrites"],"descriptors":[{"uuid":"2902"}]},{"service":"1800","characteristic":"2a00","properties":["Read"]},{"service":"1800","characteristic":"2a01","properties":["Read"]},{"service":"1800","characteristic":"2a02","properties":["Read"]},{"service":"1800","characteristic":"2a04","properties":["Read"]},{"service":"1800","characteristic":"2aa6","properties":["Read"]},{"service":"6e400001-b5a3-f393-e0a9-e50e24dcca9e","characteristic":"6e400003-b5a3-f393-e0a9-e50e24dcca9e","properties":["Notify"],"descriptors":[{"uuid":"2902"}]},{"service":"6e400001-b5a3-f393-e0a9-e50e24dcca9e","characteristic":"6e400002-b5a3-f393-e0a9-e50e24dcca9e","properties":["WriteWithoutResponse","Write"]},{"service":"1812","characteristic":"2a4e","properties":["Read","WriteWithoutResponse"]},{"service":"1812","characteristic":"2a4d","properties":["Read","Write","Notify"],"descriptors":[{"uuid":"2902"},{"uuid":"2908"}]},{"service":"1812","characteristic":"2a4d","properties":["Read","Write","Notify"],"descriptors":[{"uuid":"2902"},{"uuid":"2908"}]},{"service":"1812","characteristic":"2a4d","properties":["Read","Write","Notify"],"descriptors":[{"uuid":"2902"},{"uuid":"2908"}]},{"service":"1812","characteristic":"2a4b","properties":["Read"]},{"service":"1812","characteristic":"2a33","properties":["Read","Write","Notify"],"descriptors":[{"uuid":"2902"}]},{"service":"1812","characteristic":"2a4a","properties":["Read"]},{"service":"1812","characteristic":"2a4c","properties":["WriteWithoutResponse"]},{"service":"fee7","characteristic":"fec9","properties":["Read","Notify"],"descriptors":[{"uuid":"2902"}]},{"service":"fee7","characteristic":"fea1","properties":["Read","Indicate"],"descriptors":[{"uuid":"2902"}]},{"service":"fee7","characteristic":"fea2","properties":["Read","Write","Indicate"],"descriptors":[{"uuid":"2902"}]}]}
I've analyzed another android apps and I captured received and sended bluetooth data with this smart band and my phone with Wireshark and bluetooth-log to know what data or protocols are transmitted to get the temperature, I'm sure that the response of temperature is:
0000 02 02 20 14 00 10 00 04 00 1b 12 00 ab 00 0a ff ..
............. 0010 51 13 14 06 05 06 37 24 05
Q.....7$.
But I don't know how to convert this response to actual temperature in C°, somebody knows how to extract the real data from this smart band?
thanks in advance.
smart band link:
https://www.alibaba.com/product-detail/Cheap-High-Quantity-Bluetooth-Smart-Bracelet_1600057978967.html?spm=a2700.icbuShop.111720.6.54226ef9FPTgvq
const readCharacteristic = await device.readCharacteristicForService(userDataServiceUUID, heightCharacteristicUUID); // assuming the device is already connected
const heightInCentimeters = Buffer.from(readCharacteristic.value, 'base64').readUInt16LE(0);
https://github.com/Polidea/react-native-ble-plx/wiki/=--FAQ:-Passing-And-Retrieving-Of-Characteristic-Value

Hex to / from datetime stamp

I've an application running on Windows, I don't have the source code, the GUI presents the date as 22/06/2018 08:44, this date/time is written/read from a file. This file contains a Hex representation of the date, some examples below (the latter two have been edited by myself - hence the weird year).
2C 05 0A D4 01 (22/06/2018 08:44)
2C 06 0A D4 01 (22/06/2018 08:51)
2C 08 11 D4 01 (01/07/2018 06:53)
B4 AE 08 D4 01 (06/12/5671 13:13)
B4 AE 11 12 10 (31/07/5270 10:53)
I'm trying to understand the conversion from Hex to the GUI date/time, so that I could modify the Hex in the file direct and see the GUI date/time accordingly
Thanks
Edit: The hex numbers are standard Windows 64-bit values representing the number of 100-nanosecond intervals since January 1, 1601, with the three least significant bytes omitted and written as little endian (least significant byte first). For example, your first hex string, 2C 05 0A D4 01, means hex 01D4 0A05 2C00 0000 units at 100 nanos since January 1, 1601 UTC (this is precisely 22/06/2018 08:44:02.9898752 UTC, but your GUI omits seconds and fraction of second).
You can read more here: File Times on MSDN.
For the conversion from date and time to hex you may for example use http://www.silisoftware.com/tools/date.php?inputdate=2018-06-22T08%3A44%3A00%2B00%3A00&inputformat=text, enter your date as 2018-06-22T08:44:00+00:00 and get the hex out as 01D40A05:2A37C800. Round up so it ends in three zero bytes: 01D40A05:2B000000. Reorder the remaining bytes: 2B 05 0A D4 01.
Original answer
It’s not a date-time encoding scheme that I have met before. And from the data you have provided I am not able to deduct the full scheme. I believe I have found a bit of the scheme. I cannot get further.
Assuming some linear correspondence I first note by comparing the first two samples that a difference of 1 unit of the second group of hex digits (the second byte if you will) makes for a difference of 7 minutes. Or approximately: we don’t know if the times have seconds and maybe even fractions of seconds that are not displayed.
I used this information when comparing to the third sample. The third byte has increased by 7 from the first to the third sample (hex 11 - hex 0A = 7). Taking the increase on the second byte into account it would seem that one unit of the third byte approximates 1832 minutes, which is suspiciously close to 256 * 7 minutes = 1792 minutes. So it would seem that the 2nd and 3rd bytes have a “little endian” relationship, where the 3rd byte is more significant than the 2nd. Using this information we can obtain a little more accuracy: The difference in the times is 12849 minutes, and the difference on the 2nd and 3rd byte is hex 1108 - 0A05 = decimal 1795, so each unit is 7.1582 minutes (it agrees with the 7 minutes from before, only it’s more precise). Using this value I interpolated the second date-time from the hex value 2C 06 0A D4 01 and got 2018-06-22T08:51:09. It agrees. Hypothesis confirmed!
The information found so far suffices for encoding values between 09/06/2018 14:43 (2C 00 00 D4 01) and 01/05/2019 09:17 (2C FF FF D4 01) with a precision of 7 minutes. I’d be surprised if that were enough for you.
Comparing to the value in the 4th sample it would seem that one unit on the first byte corresponds to 14 128 940 minutes (26.86 years). It doesn’t divide nicely by the 7.1582 minutes from before, as we might have hoped, so I’m not sure how we might use this observation.
Comparing the last two samples it seems that the 4th and 5th byte cannot have the same little endian relationship since the 5th byte increases while the date decreases. It’s still possible, though, if we assume that at least one of the years is before the common era (“BC”) since era is not printed. Another possibility might be that the fifth byte is ignored. This leads to a unit of the fourth byte corresponding to 1 088 006 minutes. Again it bears no nice relationship to the 7.15 minutes from bytes 2 and 3, and it’s suspicously close to the unit of the first byte, so probably incorrect.
To learn more: First try to see if you get a meaningful date-time from editing (hex) 00 00 00 00 00 into your file. If you do, next try one F at a time:
F0 00 00 00 00
0F 00 00 00 00
…
00 00 00 00 0F
If this doesn’t make a pattern that is clear enough, try one bit at a time, using hex digits 1, 2, 4 and 8 instead of F.

Midi Hexa-Code Notation Different in one fie

I have those 3 Events in a Midi file:
00 FF 51 03 0E 15 C3 86 A6
20 FF 51 03 15 20 A5 83
5C FF 51 03 0E 15 C3
But what is, in this case, important is, that FF 51 stands for a Tempo Change and the 03 for the number of following Byte-Pairs describing the tempo. As it is "3 Byte Pairs" in Each Event Why are there 5 Byte Pairs describing the first Event, 4 describing the second, and 3 describing the third? (I hope the image helps)
How does the encoding program know, when a new Event starts? The File can be played without any Problems.
All three events have three data bytes.
The delta times between the events are encoded as variable-length quantities, so you have to continue to read bytes until the most significant bit is clear. The three times before each event are 00, 86 A6 20, and 83 5C, resulting in the decoded delta times of 0, 109344, and 476.

Online CRC-32 calculator result is incorrect, wrong polynomial?

I have to say that I don't really understand the mechanics of CRC-32; but I was hoping to be able to at least calculate a CRC based on a chunk.
I have a PNG with the following information: 2px by 5px, RGBa, no interlace
The image header chunk results in:
00 00 00 0d = data is 13 bytes long
49 48 44 52 = ascii for IHDR (image header)
00 00 00 02 00 00 00 05 08 06 00 00 00 = data; dimensions, bit-depth, etc.
6f b3 3d 9c = CRC
I wanted to see if CRC could be easily calculated so I tried using:
http://depa.usst.edu.cn/chenjq/www2/wl/software/crc/CRC_Javascript/CRCcalculation.htm
The calculator's default polynomial for CRC-32 is 04C11DB7.
When I plug in "0000000d4948445200000002000000050806000000" I get 35F0A255.
I looked it up on Wikipedia and tried the other various representations used by PNG (EDB88320 & 82608EDB) and I tried leaving off the length and chunk type with the various polynomials I used before; I also tried including the information before the chunk which defines the PNG signature. I never got 6fb33d9c.
Any ideas on why I can't get the right CRC via calculator?

figuring out ASCII style code [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
Iv been looking online everywhere but cannot figure out what this could be. It looks similar to ASCII but only with 2 digits in most parts instead of of one. This was the only place i thought may know what it is or could be.
(i added the spacing my self not sure if it should be here or not )
54 56 32 55 52 32 55 52 32 55 48 32 51 97 32 50 102 32 50 102 32 54 57 32 54 100
32 54 55 32 55 53 32 55 50 32 50 101 32 54 51 32 54 102 32 54 100 32 50 102 32 52
54 32 53 57 32 51 57 32 52 52 32 52 100 32 52 102 32 51 53
They are ASCII, using decimal code points, where 54 is '6', 56 is '8' and so on. Decoding that gives you:
68 74 74 70 3a 2f 2f 69 6d 67 75 72 2e 63 6f 6d 2f 46 57 37 44 4d 4f 35
But that again looks like valid ASCII code points (in hex this time) so decoding them gives you:
http://imgur.com/FY9DMO5
which leads to this image:
Now, if you look really closely at the black bit under the white square, you'll see some dots reminiscent of braille. And, in fact, the letters spelled out seem to be:
bitdotdoslashwehunger
If you enter that into a browser as bit.do/wehunger, you end up with yet another image:
As to what that is, my detective skills have reached the limit of my ability to care. Since the first image was called Day J, and this last one is called Day K, I suspect it's a puzzle of some sort and you should probably continue on your own.
In any case, if it's a job interview puzzle process and it's for the same big trendy company I'm currently interviewing for, I don't want to make it too easy for you :-)
I'll probably carry on following the trail just because I like puzzles, but I won't be publishing the results. Good luck in your hunt.