Vulkan swapchain creation causes crash with no debug information - c

I'm following vulkan-tutorial's procedure to understand vulkan, I'm now in creating swapchain. before that I've also created instance and a debug/validation layer but when I'm trying to create swapchain, the app crashes.
void createSwapChain() {
VkSurfaceFormatKHR surfaceFormat;
surfaceFormat.format=VK_FORMAT_B8G8R8A8_SRGB;
surfaceFormat.colorSpace=VK_COLOR_SPACE_SRGB_NONLINEAR_KHR;
VkPresentModeKHR presentMode=VK_PRESENT_MODE_FIFO_KHR;
int width,height;
glfwGetFramebufferSize(window, &width, &height);
VkExtent2D extent ={width,height};
uint32_t imageCount=2;//minimum cap +1
VkSurfaceCapabilitiesKHR capabilities;
vkGetPhysicalDeviceSurfaceCapabilitiesKHR(physicalDevice, surface, &capabilities);
VkSwapchainCreateInfoKHR createInfo={0};
createInfo.sType = VK_STRUCTURE_TYPE_SWAPCHAIN_CREATE_INFO_KHR;
createInfo.surface = surface;
createInfo.minImageCount = imageCount;
createInfo.imageFormat = surfaceFormat.format;
createInfo.imageColorSpace = surfaceFormat.colorSpace;
createInfo.imageExtent = extent;
createInfo.imageArrayLayers = 1;
createInfo.imageUsage = VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT;
createInfo.imageSharingMode = VK_SHARING_MODE_EXCLUSIVE;
// createInfo.queueFamilyIndexCount = 1;
// createInfo.pQueueFamilyIndices = NULL;
createInfo.preTransform = capabilities.currentTransform/*VK_SURFACE_TRANSFORM_IDENTITY_BIT_KHR*/;//swapChainSupport.capabilities.currentTransform
createInfo.compositeAlpha = VK_COMPOSITE_ALPHA_OPAQUE_BIT_KHR;
createInfo.presentMode = presentMode;
createInfo.clipped = VK_TRUE;// means obscured images have unimportant color!!
createInfo.oldSwapchain = VK_NULL_HANDLE;
if (vkCreateSwapchainKHR(device, &createInfo, NULL, &swapChain) != VK_SUCCESS)
printf("failed to create swap chain!");
}
Is there any idea? The host is eclipse with MinGW-64 -lglfw3 and -lvulkan-1 on windows 10 64-bit.
And here the graphic card information:
Available Layers:
VK_LAYER_AMD_switchable_graphics
VK_LAYER_VALVE_steam_overlay
VK_LAYER_VALVE_steam_fossilize
VK_LAYER_KHRONOS_validation
Available extensions:
VK_KHR_device_group_creation
VK_KHR_external_fence_capabilities
VK_KHR_external_memory_capabilities
VK_KHR_external_semaphore_capabilities
VK_KHR_get_physical_device_properties2
VK_KHR_get_surface_capabilities2
VK_KHR_surface
VK_KHR_win32_surface
VK_EXT_debug_report
VK_EXT_debug_utils
VK_EXT_swapchain_colorspace
Instance extension:
VK_KHR_surface
VK_KHR_win32_surface
VK_EXT_debug_utils
Availible devices:
AMD Radeon(TM) Graphics Type: 1 GeometryShader: Yes
FamilyIndex: 0 AvailibleQueueCount: 1 Surface Support: Yes Graphics | Compute | Transfer | Binding
FamilyIndex: 1 AvailibleQueueCount: 2 Surface Support: Yes | Compute | Transfer | Binding
FamilyIndex: 2 AvailibleQueueCount: 1 Surface Support: Yes | | Transfer | Binding
Availible device extensions: (The required is VK_KHR_swapchain)
VK_KHR_16bit_storage VK_KHR_8bit_storage VK_KHR_bind_memory2
VK_KHR_buffer_device_address VK_KHR_copy_commands2 VK_KHR_create_renderpass2
VK_KHR_dedicated_allocation VK_KHR_depth_stencil_resolve VK_KHR_descriptor_update_template
VK_KHR_device_group VK_KHR_draw_indirect_count VK_KHR_driver_properties
VK_KHR_dynamic_rendering VK_KHR_external_fence VK_KHR_external_fence_win32
VK_KHR_external_memory VK_KHR_external_memory_win32 VK_KHR_external_semaphore
VK_KHR_external_semaphore_win32 VK_KHR_format_feature_flags2 VK_KHR_get_memory_requirements2
VK_KHR_global_priority VK_KHR_imageless_framebuffer VK_KHR_image_format_list
VK_KHR_maintenance1 VK_KHR_maintenance2 VK_KHR_maintenance3
VK_KHR_maintenance4 VK_KHR_multiview VK_KHR_pipeline_executable_properties
VK_KHR_pipeline_library VK_KHR_push_descriptor VK_KHR_relaxed_block_layout
VK_KHR_sampler_mirror_clamp_to_edge VK_KHR_sampler_ycbcr_conversion VK_KHR_separate_depth_stencil_layouts
VK_KHR_shader_atomic_int64 VK_KHR_shader_clock VK_KHR_shader_draw_parameters
VK_KHR_shader_float16_int8 VK_KHR_shader_float_controls VK_KHR_shader_integer_dot_product
VK_KHR_shader_non_semantic_info VK_KHR_shader_subgroup_extended_types VK_KHR_shader_subgroup_uniform_control_flow
VK_KHR_shader_terminate_invocation VK_KHR_spirv_1_4 VK_KHR_storage_buffer_storage_class
Swap chain details:
Min/max images in swap chain; 1, 16
Min/max width and height 800 : 600 | 800 : 600
Pixel format codes(at least we need one no matter what!): 44
50 58 97 44 50 58 97 58 97 58
97 97 2 3 4 5 8 37 38 43
45 51 52 57 64 91 92 122
color space codes(at least we need one no matter what!): 0
0 0 0 1000104006 1000104006 1000104006 1000104006 1000104008 1000104008 1000104007
1000104007 1000104002 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
Available presentation modes:
0 (Immediate)
2 3 ( FIFO, FIFO_relaxed)

A few things:
There isn't really enough information in the problem description to allow others to locate the problem. For example, we can't tell how surface got created and we can't tell how the Vulkan device got created. It is better to post a complete reproducible example someplace and point to it.
There are a lot of hits when searching for "vulkan swapchain exception" like this one and this one. Something there may give a clue.
Based on what is provided and the links mentioned above, my best guess is that you're not enabling the swapchain extension when creating the device. Perhaps you could check that?
The validation layer should be helpful and you can find more information about it here. You might try making a vk_layer_settings.txt file and use it to set the message severity to "info" so that you can verify that the layer is active. (It will print some sort of startup message at this level) Your IDE might be swallowing the text output coming from the validation layer and the point behind doing this is to verify that you can see any validation output. It may be easier to provide a log filename in the same settings file to send the validation output to that file instead of figuring out what the IDE is doing. You can also use the vkconfig tool to apply these sorts of settings to the validation layer.

Related

Declare a queue with x-max-length programmatically using Rabbitmq-c

I am implementing a RPC function for my C application , and try to programmatically declare a queue which limits maximum number of pending messages, after reading the declaration of amqp_table_entry_t and amqp_field_value_t in amqp.h , here's my minimal code sample :
int default_channel_id = 1;
int passive = 0;
int durable = 1;
int exclusive = 0;
int auto_delete = 0;
amqp_table_entry_t *q_arg_n_elms = malloc(sizeof(amqp_table_entry_t));
*q_arg_n_elms = (amqp_table_entry_t) {.key = amqp_cstring_bytes("x-max-length"),
.value = {.kind = AMQP_FIELD_KIND_U32, .value = {.u32 = 234 }}};
amqp_table_t q_arg_table = {.num_entries=1, .entries=q_arg_n_elms};
amqp_queue_declare( conn, default_channel_id, amqp_cstring_bytes("my_queue_123"),
passive, durable, exclusive, auto_delete, q_arg_table );
amqp_rpc_reply_t _reply = amqp_get_rpc_reply(conn);
The code above always returns AMQP_RESPONSE_LIBRARY_EXCEPTION in the object of amqp_rpc_reply_t, with error message a socket error occurred , I don't see any active connection triggered by this code in web management UI of the RabbitMQ. so I think rabbitmq-c library doesn't establish a connection and just reply with error.
However everything works perfectly when I replace the argument q_arg_table with default amqp_empty_table (which means no argument).
Here are my questions :
Where can I find the code which filter the invalid key of the queue argument ? according to this article , x-max-length should be correct argument key for limiting number of messages in a queue , but I cannot figure out why the library still reports error.
Is there any example that demonstrates how to properly set up amqp_table_t passing in amqp_queue_declare(...) ?
Development environment :
RabbitMQ v3.2.4
rabbitmq-c v0.11.0
Appreciate any feedback , thanks for reading.
[Edit]
According to the server log rabbit#myhostname-sasl.log, RabbitMQ broker accepted a new connection, found decode error on receiving frame, then close connection immediately. I haven't figured out the Erlang implementation but the root cause is likely the decoding error on the table argument when declaring the queue.
131 =CRASH REPORT==== 18-May-2022::16:05:46 ===
132 crasher:
133 initial call: rabbit_reader:init/2
134 pid: <0.23706.1>
135 registered_name: []
136 exception error: no function clause matching
137 rabbit_binary_parser:parse_field_value(<<105,0,0,1,44>>) (src/rabbit_binary_parser.erl, line 53)
138 in function rabbit_binary_parser:parse_table/1 (src/rabbit_binary_parser.erl, line 44)
139 in call from rabbit_framing_amqp_0_9_1:decode_method_fields/2 (src/rabbit_framing_amqp_0_9_1.erl, line 791)
140 in call from rabbit_command_assembler:process/2 (src/rabbit_command_assembler.erl, line 85)
141 in call from rabbit_reader:process_frame/3 (src/rabbit_reader.erl, line 688)
142 in call from rabbit_reader:handle_input/3 (src/rabbit_reader.erl, line 738)
143 in call from rabbit_reader:recvloop/2 (src/rabbit_reader.erl, line 292)
144 in call from rabbit_reader:run/1 (src/rabbit_reader.erl, line 273)
145 ancestors: [<0.23704.1>,rabbit_tcp_client_sup,rabbit_sup,<0.145.0>]
146 messages: [{'EXIT',#Port<0.31561>,normal}]
147 links: [<0.23704.1>]
148 dictionary: [{{channel,1},
149 {<0.23720.1>,{method,rabbit_framing_amqp_0_9_1}}},
150 {{ch_pid,<0.23720.1>},{1,#Ref<0.0.20.156836>}}]
151 trap_exit: true
152 status: running
153 heap_size: 2586
154 stack_size: 27
155 reductions: 2849
156 neighbours:
RabbitMQ may not support unsigned integers as table values.
Instead try using a signed 32 or 64-bit number (e.g., .value = {.kind = AMQP_FIELD_KIND_I32, .value = {.i32 = 234 }}).
Also the RabbitMQ server logs may contain additional debugging information that can help understand errors like this as well as the amqp_error_string2 function can be used to translate error-code into an error-string.

How is this array of floats encoded?

I am trying to decode an array of data from a piece of legacy equipment in to a more useful format.
I have the following base64 encoded string:
iWGLvgUjF73/tW0+EAZDvf+cYj6pPw+9YLFjPqYCnbzgvm4+BEYVvBvOfD4QtBi8zdSCPlI7lrzg
q4I+HYb1vMupfT5sbxm9iYxyPh3JGL3IIGs+onj6vBnhaT6yQa28UrNuPi01Xrx22nY+PZMvvMi2
fj5kJlu8/l+BPrdVo7wT64A+BjjfvL1SfD545QK9i191PiZXBL0Ts28+s/fnvKnobT4wb7K8zOpw
PlHyg7xGMXY+KsVQvHnXfD7EdF68z++APqVHlrxrT4E+kBvOvD21fj5wYf+8ItJ3PoZrCL1hBXE+
/VL8vF5MbT5hJcm8TXNuPi1FjbyPRHQ+asVFvDCTfD6mtT+8GrKBPgghibxLyII+z13NvKfagD7g
hAi900l5PttTGL356G8+8SMPvQxIaj5esd+8J/NqPugjkbzj/HE+pr0svGOmfD5K6Bi8pPqCPnOY
e7yIpYQ+tivYvMI7gj7xKBi9ipJ5Pu4oLr1MuW0+Y38jvdhgZj5ccPq8hdpmPp8UmLzUJG8+IOcg
vCzYez5yYwq8LFKDPpmAgLxw/IQ+psvqvCPagT6W0Sa9quh2PuOXPL0nbWk+CUksvdTGYT77Sfq8
jIdjPkeyi7wg320+Nyj8uyhIfD48tOq72vGDPriIhbzoN4U+VQf9vMRNgT5UezO9WAd0PtUvR73p
vWU+rkwxvUBhXj7rJvi8gxlhPqXPgrxUuGw+G4bYu6sIfD6aL+C74tqDPkVXjLzVxYQ+LHUFvVVC
gD61njq9uz5xPsXTS70O2mI+MPMxvdDVWz5Acva8jiRfPos3fbyHRms+q63Ruy6nej75hOm7V/iC
Pi0yj7xewYM+BqsGvXt/fj7wSzq9dG1vPt35Sr2WamE+a8MxvWd9Wj68qfi8WmddPrMPhbxntmg+
pGTvu7Aidz6Fufm7gvqAPsYMi7w/6oE+tUL+vL7bez6cOC+92BhuPhN/P73vAmE+r3ApvUxvWj4P
q/G8p9VcPoBlhbzrBmc+cHEAvHd6dD47iPe7vrN+PgXsgLy4ioA+3trovNU9ej4gGSK9AOVtPsxs
M71Gr2E+9G0hvfLoWj7oCey8WElcPvpeiLwjMmU+xU4AvNaccT6B6tW7cwV8Pt7SVbwKjn8+S+rI
vIS9ej5VyBG9DhlwPtaJJ71fZmQ+DrwdvXK4XD5OafS8ITxcPr/Xl7zA02I+t9gbvLGZbT7qmtG7
Iud3PqUdK7xx83w+nd2hvMjJej56s/W8inhyPh6hFL2EGWg+mTYUvUswYD66P/K8TwJePimdo7xx
aWI+bBk1vPRraz6T6Ne7Uyx1PhbZCLzVdHs+9oKBvAeFez6EPc682aZ1Pnn1A72Xgmw+DzYLvZtv
ZD509PO8S7ZgPp47sLzkD2M+iSNRvERTaj7W8ei7DshzPuK35rsabHs+o8BNvBPKfT7kl6+8DTd6
PvSp87y9SXI+cSYLvdOBaT7POQW9foVjPvxO2LxbkGI+rz2SvOUzZz4YTy68WVpvPkFI/ruws3c+
hyMkvB6yfD7npIm8i2R8Pmrhzrx34nY+HUQBvciVbj6mEgi99AhnPjSf8rwZJ2M+7gi3vGTEZD7g
EWW8/zVrPkJ+BLzd7HM+5Dfku0Dgez4WUDm8Npd/PgXlnrybpn0+jUHmvJqVdj4ASgq9u2xtPhAT
DL3m7GU+b2XrvOJYYz5Ue6O84tZmPjYwNbxyoW8+tbm0u+yqej4Tk9S7HaWBPifMaLzwy4I+nb3U
vC6rfz4VTBi914NzPh/yLr2l82U+mPIhvRbwXD5Qmei8piVdPmqVXLxIgWc+/xRtuvcbeT4rYTE7
9EiFPviA27sgAIk+dp/bvJZEhD76FEW9hQJxPgmSa710iVg+uzJDvZ9tTj5gUru8euJZPld95zr4
PnQ+tKopPIbGhT4P+wu7FbSIPjMbz7ydN4M+V6wwvfxRdT62qES9Y9RnPmvWLb2ak2E+sGgEvWY0
Yj7zqLa8en9nPj/xeryF6G4+RHJHvKlbdj7xY1a80318Ppcpj7yRgX8+Py7IvLs7fj4iaQS9xHF4
PpxWHr3btW8+D3wnvSq+Zj6NLhm9jV1hPoaf77zwEGI+9MWavMR6aT4lkCy8F3N1PsR/CLzWd4A+
kHVrvCtGgz5v5tq8
When adding trailing padding and decoding this from base64, it produces an unknown binary format.
What I know so far based on limited inspection of the application:
It is definitely base64.
This array describes a series of floating point data (with values between 19 and 50) that consists of 201 points.
The application that created this was likely written in .NET.
How is this data encoded, and can you provide psuedo-code to decode it?
Update #1:
This data describes a return loss measurement waveform from an old network analyser.
The expected values above are based on what the instrument displays, and it is possible that they are calculated from real and imaginary components.
Update #2:
I've found there was also a CSV version of the data for this series. Expected values are:
28.6740250379346, 26.031723427971, 26.6849726930916, 27.5095233036572, 27.9755283611409, 28.0419902829292, 27.9918713318024, 28.0331481409078, 28.2620361924923, 29.1899991143532, 30.4746778667205, 31.9841888600965, 32.7562027026775, 32.2032446202011, 31.0251062040461, 30.1158617686259, 29.5968352710132, 29.8991302542384, 30.7711739051407, 32.5985879649759, 35.465787543584, 38.4033014264434, 36.2400347268325, 33.230539516557, 30.816214031517, 29.493776099706, 28.9641221620517, 29.3271399473768, 30.5497479471498, 32.9092924040263, 36.23602780908, 36.6766990656565, 32.9072309537322, 29.8008349575816, 27.8506153462939, 26.8255601987161, 26.7773337706284, 27.6450826739213, 29.6698279365727, 32.925219461411, 34.9915552473819, 31.6841927998324, 28.219566759529, 25.990640197895, 24.8525028738483, 24.6159871249645, 25.2752655673475, 26.9870507463537, 29.9877735491643, 33.2675296198038, 31.6015986278861, 27.8240493530138, 25.2742229688217, 23.9448603205908, 23.5140204346426, 23.9914986842046, 25.5009034820686, 28.1555920133881, 31.3075467263927, 30.7066273219751, 27.2707536503799, 24.7348022011574, 23.2637028240862, 22.7794008043094, 23.1669728824416, 24.5474786226331, 26.9949958437379, 30.2488348819328, 30.6013906923573, 27.3394012893084, 24.6326441335966, 23.0411076555662, 22.4181795795548, 22.7062561945124, 23.8692711954611, 26.163804153602, 29.606819207681, 31.2543679681834, 28.1493119289191, 25.0924674969376, 23.2520785937701, 22.4092737645517, 22.5015858777069, 23.4763598655373, 25.5208843109912, 28.9618678298617, 32.6403317308031, 30.3536019856501, 26.5991532707429, 24.2773569962831, 23.1127901052235, 22.9043583677862, 23.6093457155953, 25.3499073692444, 28.4637157202952, 32.8016120624956, 32.4896370664701, 28.3239184297021, 25.5279166849078, 24.0185490655501, 23.5330605365427, 23.8948677486768, 25.2054578354006, 27.7143031565687, 31.5869657438201, 33.7333955992785, 30.3948949895062, 27.1037601765126, 25.2161101159979, 24.3558529725873, 24.3231491126384, 25.2139427454679, 27.1233066134797, 30.3453761997478, 34.4047437237606, 33.8064220094595, 29.9215033359328, 27.3307978071688, 25.8801149514006, 25.4718657467003, 25.8501031953971, 27.1888665858689, 29.5756748124031, 32.9812339884177, 35.3068159226901, 32.6414213429246, 29.5799546795568, 27.7291120251878, 26.9050286745762, 26.9075167887431, 27.7591889971496, 29.3670540494547, 31.7578198149182, 33.5065256564295, 32.6776622084245, 30.4203840091006, 28.688025867147, 27.7417192975661, 27.4916484304414, 27.9791419175041, 29.2902681126682, 31.4107407957172, 33.4602036884894, 33.9200015192937, 32.1201008630103, 30.1453133278815, 28.7841082718969, 28.136959973426, 28.109171467367, 28.8259362791248, 30.0289196496445, 31.326134345957, 32.0708833202456, 31.4950426416152, 30.1423739250155, 29.0036769811377, 28.2190253962644, 28.1086422581195, 28.4750473325836, 29.1942813484775, 29.7608412256926, 29.6876433997282, 28.689538924267, 27.2407586615062, 26.0067421520125, 25.1638342823008, 24.8250524294419, 24.9395261449731, 25.4584143514754, 25.8777584307235, 25.6465050536004, 24.5707670056442, 23.0511544464452, 21.7615681906835, 20.9761497089273, 20.7854547053249, 21.2816973223554, 22.253260423558, 23.2052378948627, 23.4706372938485, 23.2944515491774, 23.1680235174658, 23.5290621578115, 24.4333231530622, 25.8639616096787, 27.9401749621508, 30.7364242326027, 33.9420488375473, 35.6377896682262, 33.4869702934454, 30.5820901568128, 28.3404467791117, 26.8270077060156, 26.0018669972732, 25.9446717292131, 26.5828002183748, 28.0360464264943, 30.0958735279379, 31.2921110009257, 29.5253906387702, 26.6971475290807
To advance the cause,
iWGLvgUjF73/tW0+EAZDvf+cYj6pPw+9YLFjPqYCnbzgvm4+BEYVvBvOfD4QtBi8zdSCPlI7lrzgq4I+HYb1vMupfT5sbxm9iYxyPh3JGL3IIGs+onj6vBnhaT6yQa28UrNuPi01Xrx22nY+PZMvvMi2fj5kJlu8/l+BPrdVo7wT64A+BjjfvL1SfD545QK9i191PiZXBL0Ts28+s/fnvKnobT4wb7K8zOpwPlHyg7xGMXY+KsVQvHnXfD7EdF68z++APqVHlrxrT4E+kBvOvD21fj5wYf+8ItJ3PoZrCL1hBXE+/VL8vF5MbT5hJcm8TXNuPi1FjbyPRHQ+asVFvDCTfD6mtT+8GrKBPgghibxLyII+z13NvKfagD7ghAi900l5PttTGL356G8+8SMPvQxIaj5esd+8J/NqPugjkbzj/HE+pr0svGOmfD5K6Bi8pPqCPnOYe7yIpYQ+tivYvMI7gj7xKBi9ipJ5Pu4oLr1MuW0+Y38jvdhgZj5ccPq8hdpmPp8UmLzUJG8+IOcgvCzYez5yYwq8LFKDPpmAgLxw/IQ+psvqvCPagT6W0Sa9quh2PuOXPL0nbWk+CUksvdTGYT77Sfq8jIdjPkeyi7wg320+Nyj8uyhIfD48tOq72vGDPriIhbzoN4U+VQf9vMRNgT5UezO9WAd0PtUvR73pvWU+rkwxvUBhXj7rJvi8gxlhPqXPgrxUuGw+G4bYu6sIfD6aL+C74tqDPkVXjLzVxYQ+LHUFvVVCgD61njq9uz5xPsXTS70O2mI+MPMxvdDVWz5Acva8jiRfPos3fbyHRms+q63Ruy6nej75hOm7V/iCPi0yj7xewYM+BqsGvXt/fj7wSzq9dG1vPt35Sr2WamE+a8MxvWd9Wj68qfi8WmddPrMPhbxntmg+pGTvu7Aidz6Fufm7gvqAPsYMi7w/6oE+tUL+vL7bez6cOC+92BhuPhN/P73vAmE+r3ApvUxvWj4Pq/G8p9VcPoBlhbzrBmc+cHEAvHd6dD47iPe7vrN+PgXsgLy4ioA+3trovNU9ej4gGSK9AOVtPsxsM71Gr2E+9G0hvfLoWj7oCey8WElcPvpeiLwjMmU+xU4AvNaccT6B6tW7cwV8Pt7SVbwKjn8+S+rIvIS9ej5VyBG9DhlwPtaJJ71fZmQ+DrwdvXK4XD5OafS8ITxcPr/Xl7zA02I+t9gbvLGZbT7qmtG7Iud3PqUdK7xx83w+nd2hvMjJej56s/W8inhyPh6hFL2EGWg+mTYUvUswYD66P/K8TwJePimdo7xxaWI+bBk1vPRraz6T6Ne7Uyx1PhbZCLzVdHs+9oKBvAeFez6EPc682aZ1Pnn1A72Xgmw+DzYLvZtvZD509PO8S7ZgPp47sLzkD2M+iSNRvERTaj7W8ei7DshzPuK35rsabHs+o8BNvBPKfT7kl6+8DTd6PvSp87y9SXI+cSYLvdOBaT7POQW9foVjPvxO2LxbkGI+rz2SvOUzZz4YTy68WVpvPkFI/ruws3c+hyMkvB6yfD7npIm8i2R8Pmrhzrx34nY+HUQBvciVbj6mEgi99AhnPjSf8rwZJ2M+7gi3vGTEZD7gEWW8/zVrPkJ+BLzd7HM+5Dfku0Dgez4WUDm8Npd/PgXlnrybpn0+jUHmvJqVdj4ASgq9u2xtPhATDL3m7GU+b2XrvOJYYz5Ue6O84tZmPjYwNbxyoW8+tbm0u+yqej4Tk9S7HaWBPifMaLzwy4I+nb3UvC6rfz4VTBi914NzPh/yLr2l82U+mPIhvRbwXD5Qmei8piVdPmqVXLxIgWc+/xRtuvcbeT4rYTE79EiFPviA27sgAIk+dp/bvJZEhD76FEW9hQJxPgmSa710iVg+uzJDvZ9tTj5gUru8euJZPld95zr4PnQ+tKopPIbGhT4P+wu7FbSIPjMbz7ydN4M+V6wwvfxRdT62qES9Y9RnPmvWLb2ak2E+sGgEvWY0Yj7zqLa8en9nPj/xeryF6G4+RHJHvKlbdj7xY1a80318Ppcpj7yRgX8+Py7IvLs7fj4iaQS9xHF4PpxWHr3btW8+D3wnvSq+Zj6NLhm9jV1hPoaf77zwEGI+9MWavMR6aT4lkCy8F3N1PsR/CLzWd4A+kHVrvCtGgz5v5tq8
Converts to hex dump
89618bbe 052317bd ffb56d3e 100643bd ff9c623e a93f0fbd 60b1633e a6029dbc e0be6e3e 044615bc 1bce7c3e 10b418bc cdd4823e 523b96bc e0ab823e 1d86f5bc cba97d3e 6c6f19bd 898c723e 1dc918bd c8206b3e a278fabc 19e1693e b241adbc 52b36e3e 2d355ebc 76da763e 3d932fbc c8b67e3e 64265bbc fe5f813e b755a3bc 13eb803e 0638dfbc bd527c3e 78e502bd 8b5f753e 265704bd 13b36f3e b3f7e7bc a9e86d3e 306fb2bc ccea703e 51f283bc 4631763e 2ac550bc 79d77c3e c4745ebc cfef803e a54796bc 6b4f813e 901bcebc 3db57e3e 7061ffbc 22d2773e 866b08bd 6105713e fd52fcbc 5e4c6d3e 6125c9bc 4d736e3e 2d458dbc 8f44743e 6ac545bc 30937c3e a6b53fbc 1ab2813e 082189bc 4bc8823e cf5dcdbc a7da803e e08408bd d349793e db5318bd f9e86f3e f1230fbd 0c486a3e 5eb1dfbc 27f36a3e e82391bc e3fc713e a6bd2cbc 63a67c3e 4ae818bc a4fa823e 73987bbc 88a5843e b62bd8bc c23b823e f12818bd 8a92793e ee282ebd 4cb96d3e 637f23bd d860663e 5c70fabc 85da663e 9f1498bc d4246f3e 20e720bc 2cd87b3e 72630abc 2c52833e 998080bc 70fc843e a6cbeabc 23da813e 96d126bd aae8763e e3973cbd 276d693e 09492cbd d4c6613e fb49fabc 8c87633e 47b28bbc 20df6d3e 3728fcbb 28487c3e 3cb4eabb daf1833e b88885bc e837853e 5507fdbc c44d813e 547b33bd 5807743e d52f47bd e9bd653e ae4c31bd 40615e3e eb26f8bc 8319613e a5cf82bc 54b86c3e 1b86d8bb ab087c3e 9a2fe0bb e2da833e 45578cbc d5c5843e 2c7505bd 5542803e b59e3abd bb3e713e c5d34bbd 0eda623e 30f331bd d0d55b3e 4072f6bc 8e245f3e 8b377dbc 87466b3e abadd1bb 2ea77a3e f984e9bb 57f8823e 2d328fbc 5ec1833e 06ab06bd 7b7f7e3e f04b3abd 746d6f3e ddf94abd 966a613e 6bc331bd 677d5a3e bca9f8bc 5a675d3e b30f85bc 67b6683e a464efbb b022773e 85b9f9bb 82fa803e c60c8bbc 3fea813e b542febc bedb7b3e 9c382fbd d8186e3e 137f3fbd ef02613e af7029bd 4c6f5a3e 0fabf1bc a7d55c3e 806585bc eb06673e 707100bc 777a743e 3b88f7bb beb37e3e 05ec80bc b88a803e dedae8bc d53d7a3e 201922bd 00e56d3e cc6c33bd 46af613e f46d21bd f2e85a3e e809ecbc 58495c3e fa5e88bc 2332653e c54e00bc d69c713e 81ead5bb 73057c3e ded255bc 0a8e7f3e 4beac8bc 84bd7a3e 55c811bd 0e19703e d68927bd 5f66643e 0ebc1dbd 72b85c3e 4e69f4bc 213c5c3e bfd797bc c0d3623e b7d81bbc b1996d3e ea9ad1bb 22e7773e a51d2bbc 71f37c3e 9ddda1bc c8c97a3e 7ab3f5bc 8a78723e 1ea114bd 8419683e 993614bd 4b30603e ba3ff2bc 4f025e3e 299da3bc 7169623e 6c1935bc f46b6b3e 93e8d7bb 532c753e 16d908bc d5747b3e f68281bc 07857b3e 843dcebc d9a6753e 79f503bd 97826c3e 0f360bbd 9b6f643e 74f4f3bc 4bb6603e 9e3bb0bc e40f633e 892351bc 44536a3e d6f1e8bb 0ec8733e e2b7e6bb 1a6c7b3e a3c04dbc 13ca7d3e e497afbc 0d377a3e f4a9f3bc bd49723e 71260bbd d381693e cf3905bd 7e85633e fc4ed8bc 5b90623e af3d92bc e533673e 184f2ebc 595a6f3e 4148febb b0b3773e 872324bc 1eb27c3e e7a489bc 8b647c3e 6ae1cebc 77e2763e 1d4401bd c8956e3e a61208bd f408673e 349ff2bc 1927633e ee08b7bc 64c4643e e01165bc ff356b3e 427e04bc ddec733e e437e4bb 40e07b3e 165039bc 36977f3e 05e59ebc 9ba67d3e 8d41e6bc 9a95763e 004a0abd bb6c6d3e 10130cbd e6ec653e 6f65ebbc e258633e 547ba3bc e2d6663e 363035bc 72a16f3e b5b9b4bb ecaa7a3e 1393d4bb 1da5813e 27cc68bc f0cb823e 9dbdd4bc 2eab7f3e 154c18bd d783733e 1ff22ebd a5f3653e 98f221bd 16f05c3e 5099e8bc a6255d3e 6a955cbc 4881673e ff146dba f71b793e 2b61313b f448853e f880dbbb 2000893e 769fdbbc 9644843e fa1445bd 8502713e 09926bbd 7489583e bb3243bd 9f6d4e3e 6052bbbc 7ae2593e 577de73a f83e743e b4aa293c 86c6853e 0ffb0bbb 15b4883e 331bcfbc 9d37833e 57ac30bd fc51753e b6a844bd 63d4673e 6bd62dbd 9a93613e b06804bd 6634623e f3a8b6bc 7a7f673e 3ff17abc 85e86e3e 447247bc a95b763e f16356bc d37d7c3e 97298fbc 91817f3e 3f2ec8bc bb3b7e3e 226904bd c471783e 9c561ebd dbb56f3e 0f7c27bd 2abe663e 8d2e19bd 8d5d613e 869fefbc f010623e f4c59abc c47a693e 25902cbc 1773753e c47f08bc d677803e 90756bbc 2b46833e 6fe6dabc
402 32-bits.
Or more nicely formatted and re-endian-ized.
Looks like values are encoded as IEEE 32-bit float scaled up by about 122 or some magic number - depending on which values first expected value is 28.62 and the last is 31.32 map to.
0 BE8B6189 BD172305 -0.272229 -0.036899*
1 3E6DB5FF BD430610 0.232140* -0.047613
2 3E629CFF BD0F3FA9 0.221302 -0.034973
3 3E63B160 BC9D02A6 0.222356 -0.019166
4 3E6EBEE0 BC154604 0.233150 -0.009111
5 3E7CCE1B BC18B410 0.246880 -0.009320
6 3E82D4CD BC963B52 0.255530 -0.018339
7 3E82ABE0 BCF5861D 0.255218 -0.029971
8 3E7DA9CB BD196F6C 0.247718 -0.037460
9 3E728C89 BD18C91D 0.236864 -0.037301
10 3E6B20C8 BCFA78A2 0.229617 -0.030575
...
195 3E615D8D BCEF9F86 0.220083 -0.029251
196 3E6210F0 BC9AC5F4 0.220768 -0.018893
197 3E697AC4 BC2C9025 0.228007 -0.010532
198 3E757317 BC087FC4 0.239697 -0.008331
199 3E8077D6 BC6B7590 0.250914 -0.014371*
200 3E83462B BCDAE66F 0.256395* -0.026721
... it is possible that they are calculated from real and imaginary components.
Note, with ignoring the first data value:
last complex pair magnitude / first complex pair magnitude
|-0.014371 + 0.256395 * i| / | -0.036899 + 0.232140 * i| is 1.093...
Much like 31.32/28.62 is 1.094...

How to interpret oglmx function in R programming?

am currently working on a project wherein am supposed to model public acceptance on pricing schemes.
The independent variables being used for model:- Age, gender,income etc... which are categorical in nature, so I converted them into factored variables using as.factor() function.
Age Gender Income
0 1 2
0 0 0
0 0 1
I have certain other variables like Transit satisfaction, Environment improvement etc... which are ordered factors on scale of 1 to 5 . 1 being extremely dissatisfied and 5 being very satisfied.
My model is as follows :-
mdl = oglmx( prcing ~Ann_In1+Edu+Env_imp+rs_imp,data=cpdat, link = "logit", constantMEAN = F, constantSD = F, delta = 0, threshparam = NULL)
summary(mdl)
Estimate Std. error t value Pr(>|t|)
Ann_In11 0.1605540 0.3021613 0.5314 0.5951749
Ann_In12 -0.9556992 0.4218504 -2.2655 0.0234824 *
Edu1 0.0710699 0.2678081 0.2654 0.7907196
Edu2 1.0732587 0.7112519 1.5090 0.1313061
Env_imp.L -0.8524288 0.4899275 -1.7399 0.0818752 .
Env_imp.Q 0.0784353 0.3936332 0.1993 0.8420595
Env_imp.C 0.4589036 0.4498676 1.0201 0.3076878
Env_imp^4 -0.2219108 0.4423486 -0.5017 0.6159032
rd_sft.L 2.6335035 0.7362206 3.5771 0.0003475 ***
rd_sft.Q -0.7064391 0.5773880 -1.2235 0.2211377
rd_sft.C 0.0130127 0.4408486 0.0295 0.9764519
rd_sft^4 -0.2886550 0.3582014 -0.8058 0.4203318
I obtained the results as below. Am unable to interpret the results. Any leads in this can be very helpful.
In case of rd_sft (road safety ) as rd_sft.L (linear) is signiicant than other levels, can we neglect the other levels i.e Q,C,^4 in model formation ??
please through some light on model formulation and its intepretation as i am new to R.

How to initialize a DT028ATFT display

I am trying to initialize a DT028ATFT-TS display on an STM32F10B main board. The system worked with DT028TFT-TS before, but that display has been discontinued. As a result of using the new diplay, the interface also had to change from ILI9320 to ILI9341. I am now basically trying to initialize the new display in a configuration that would be equivalent to what I had before.
The problem I am facing is that the display image ends up showing horizontal streaks randomly distributed (slightly different at every startup) with a bit of a flicker. And, at times (not sure if related), it just shows the backlight and nothing else - no streaks, no test image. The test image is just one big red square (100x100) displayed at x=100, y=50. You can see the effect of the problem here: Streaked Display Image.
The following is part of the initialization code that I've used - part of it taken as such from DisplayTech's sample code offered on their website, part of it customized. I've excluded commands from the sample code that are not documented under ILI9341 (probably vendor customization) and the gamma correction parameters, just to save some space. Any help in finding out where I went wrong would be appreciated.
// DT028ATFT LCD init - ILI9341:
// Frame Rate Control
SPI_WriteCMD(0xB1);
SPI_WriteDAT(0x00); // division ratio: 1
SPI_WriteDAT(0x10); // 16 clocks per line
// Power Control
SPI_WriteCMD(0xC0);
SPI_WriteDAT(0x25); // GVDD = 4.70V
SPI_WriteCMD(0xC1);
SPI_WriteDAT(0x03); // VCL=VCI x 2, VGH=VCI x 6, VGL=-VCI x 3
// VCOM Control
SPI_WriteCMD(0xC5);
SPI_WriteDAT(0x5C); // VCOMH = 5.000 V
SPI_WriteDAT(0x4C); // VCOML = -0.600 V
SPI_WriteCMD(0xC7);
SPI_WriteDAT(0x94); // VCOMH = VMH - 44, VCOML = VML - 44
// Memory Access Control
SPI_WriteCMD(0x36);
SPI_WriteDAT(0x08); // BGR=1, Normal addr order and refresh direction
// Write CTRL Display
SPI_WriteCMD(0x53);
SPI_WriteDAT(0x24); // BCTRL=1, DD=0, BL=1
// Display Function Control
SPI_WriteCMD(0xB6);
SPI_WriteDAT(0x00); // Normal scan, V63 pos pol / V0 neg pol
SPI_WriteDAT(0xA0); // LCD normally white, G1 to G320, S720 to S1
SPI_WriteDAT(0x27); // NL = 320
SPI_WriteDAT(0x00); // PCDIV not used
// Entry Mode Set
SPI_WriteCMD(0xB7);
SPI_WriteDAT(0x06); // Normal display for G1-G320 output, Low voltage detection enabled
// Column Address Set
SPI_WriteCMD(0x2A);
SPI_WriteDAT(0x00);
SPI_WriteDAT(0x00); // Start Column = 0
SPI_WriteDAT(0x00);
SPI_WriteDAT(0xEF); // End Column = 239
// Page Address Set
SPI_WriteCMD(0x2B);
SPI_WriteDAT(0x00);
SPI_WriteDAT(0x00); // Start Page = 0
SPI_WriteDAT(0x01);
SPI_WriteDAT(0x3F); // End Page = 319
// Gamma Set
SPI_WriteCMD(0x26);
SPI_WriteDAT(0x01); // Gamma Curve 1 selected (G2.2)
// Pixel Format Set
SPI_WriteCMD(0x3A);
SPI_WriteDAT(0x55); // 16bits/pixel (RGB and MCU i/f)
// Interface Control
SPI_WriteCMD(0xF6);
SPI_WriteDAT(0x00); // image data not wrapped around (exceeding data ignored)
SPI_WriteDAT(0x00); // MSB used also as LSB for R and B (64k colours)
SPI_WriteDAT(0x00); // Disp Op Mode: internal clk, GRAM access: Sys I/F, 1 transf/pxl (16bit 64k colours)
// RGB Interface Signal Control
SPI_WriteCMD(0xB0);
SPI_WriteDAT(0xC0); // BypassMode=1, RCM=2, VSPL=0, HSPL=0, DPL=0, EPL=0
// Sleep Mode off (DC/DC conv enabled, internal osc started)
SPI_WriteCMD(0x11);
Dly100us((void*)1200);
// Display ON
SPI_WriteCMD(0x29);
// ===============================
your problem sounds like a timing issue. Have you tried reducing the frame rate? that should relax the display timing. you are setting it to 119 Hz.
are you doing a proper reset before the init?
you can compare with other implementations for the ILI9341 controller:
Example
Atmel Library

extjs problem calculation of rows

i have a table
Fields
class 1
class 2
class 3
class 4
a1
10
240
340
401
a2
12
270
340
405
a3
12
270
340
405
a4
15
270
360
405
a5
17
720
530
450
i have this in grid as well as in Json.store , what i have to do is perform mathematical calculation each time the grid is refreshed by "table name".reconfigure(..... , ....)
consider the column "class1" ,
value(a5) = ( value(a1)+ 2*value(a2) + 3*value(a3) ) /value(a4)
can anybody please help he on this problem ,
I will be very very Thankful for help :)
As I'm not sure what aspect of the problem you are having difficulty with, I'll address both at a high level.
Generally speaking you want to have your reconfigure method update the Ext Store, which will then trigger an event that the Grid should handle. Basically, change the Store and your Grid will be updated automatically.
As far as generating the correct new row... it seems fairly straightforward - a rough pass:
/*for each field foo_X through foo_N:*/
var lastElementIndex = store.data.size-1;
var total = 0;
for (var i=0; i<; i++) {
if (i != lastElementIndex) {
total += store.data[i].get(foo_X)*i;
} else {
total = total/store.data[i].get(foo_x);
}
}
/*construct your json object with the field foo*/
/*after looping through all your fields, create your record and add it to the Store*/

Resources