This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Help: why is the output is different than input?

FormerMember
FormerMember

Hello!

I'm trying to get the 16 bit ADC value as 2 of 8 bit array from nRF51 development kit over bluetooth to MCP, but when it displays on the MCP the value is "swap" for example is input value is 0X1020 then, in the MCP it shows "(0x) 20-10

Here is the code:

    uint32_t adc_update(ble_adc_t * p_bms, uint16_t adc)
{
	uint32_t err_code = NRF_SUCCESS;
	ble_gatts_value_t gatts_value;
	
	// Initialize value struct.
  memset(&gatts_value, 0, sizeof(gatts_value));
	
	gatts_value.len     = sizeof(uint16_t);
	gatts_value.offset  = 0;
	gatts_value.p_value = (uint8_t *)&adc;
	
	if(p_bms->bvm_count== BLE_ADC_MAX_BUFFERED_MEASUREMENTS)
	{
		// The voltage measurement buffer is full, delete the oldest value
        memmove(&p_bms->adc_buffer[0],
                &p_bms->adc_buffer[1],
                (BLE_ADC_MAX_BUFFERED_MEASUREMENTS - 1) * sizeof(uint16_t));
        p_bms->bvm_count--;
	}

	// Add new value
	uint16_t ab = 0x1020;
	p_bms->adc_buffer[p_bms->bvm_count++] = ab;
	
		
	// Update database.
	err_code = sd_ble_gatts_value_set(p_bms->conn_handle,
																			p_bms->sample_level_handles.value_handle,
																			&gatts_value);
    	    	
	// Send value if connected and notifying.
        if ((p_bms->conn_handle != BLE_CONN_HANDLE_INVALID) && p_bms->is_notification_supported)
        {
					uint8_t initial_sample_level[MAX_ADC_LEN];
					uint16_t len;
					uint16_t hvx_len;
					
          ble_gatts_hvx_params_t hvx_params;
					len = adc_encode(p_bms,initial_sample_level);
					hvx_len = len;

            memset(&hvx_params, 0, sizeof(hvx_params));
            hvx_params.handle = p_bms->sample_level_handles.value_handle;
            hvx_params.type   = BLE_GATT_HVX_NOTIFICATION;
						hvx_params.offset = 0;
					  hvx_params.p_len  = &hvx_len;
						hvx_params.p_data = initial_sample_level;

            err_code = sd_ble_gatts_hvx(p_bms->conn_handle, &hvx_params);
						if ((err_code == NRF_SUCCESS) && (hvx_len != len))
						{
								err_code = NRF_ERROR_DATA_SIZE;
						}
				}
        else
        {
            err_code = NRF_ERROR_INVALID_STATE;
        }

    return err_code;
}

Please look closer to this piece of code:

// Add new value
	uint16_t ab = 0x1020;
	p_bms->adc_buffer[p_bms->bvm_count++] = ab;

If the value of ab = 0x1020 the MCP will display (0x) 20 - 10

Here is the screen shot of what it display on MCP.

image description

I've tried to fixed this all day today, but still can't fix it.

Any help is greatly appreciative!

Parents
  • The value is transferred little-endian, the MCP just shows the bytes in order they arrive. Nothing needs swapping, it's fine the way it is. The MCP is just a viewer of data, if you have an actual application on the other side reading the data it would know the two bytes are little-endian and interpret them correctly.

    You've tried all day to fix a problem you don't have.

  • I have no clue - I've never used the Master Control Panel so I have no idea what functions it has and what data types it can display. I use Lightblue usually and in that you can tell it you have 16 bit little endian data and it shows it as a number. Perhaps if you add the data type characteristic for that data the MCP will display it in that format, and perhaps it won't.

    But honestly this is just like looking at data with a debugger, you see bytes because that's how the data actually is represented. The MCP always seemed to me to be the equivalent of a debugger for bluetooth.

Reply
  • I have no clue - I've never used the Master Control Panel so I have no idea what functions it has and what data types it can display. I use Lightblue usually and in that you can tell it you have 16 bit little endian data and it shows it as a number. Perhaps if you add the data type characteristic for that data the MCP will display it in that format, and perhaps it won't.

    But honestly this is just like looking at data with a debugger, you see bytes because that's how the data actually is represented. The MCP always seemed to me to be the equivalent of a debugger for bluetooth.

Children
No Data
Related