. * * window.aa needs to exist and be usable by ANY module's script, * however early it runs - main-nav's script, for one, runs near * the top of

91̽»¨

, well before the real search-insights.js * so the download * begins as early as before. Repeat calls share the same downloads, a * failed load is retried on the next call, and the versions / SRI * hashes live only here. * * Algolia Insights is unaffected: window.aa above is still created in * on every page and queues events until search-insights loads. * * window.loadAlgoliaLibs({ priority: 'high' }) (Oct 2026): used by the * /search page, where the first results wait on these libraries. Chrome * gives async scripts low priority, behind images and fonts; this asks * for high instead (fetchpriority). Only the first call for a library * sets its priority - later calls share that download. */ (function (win, doc) { var LIBS = [ { ready: function () { return !!win['algoliasearch/lite']; }, src: 'https://cdn.jsdelivr.net/npm/algoliasearch@5.52.1/dist/lite/builds/browser.umd.js', integrity: 'sha256-I2oYUIvhx1g6l4lTP+yoERbzLIHKzw4AKaBRQPwIeDY=' }, { ready: function () { return !!win.instantsearch; }, src: 'https://cdn.jsdelivr.net/npm/instantsearch.js@4.98.0/dist/instantsearch.production.min.js', integrity: 'sha256-ngmqZk4WBxUw257aMYZayyNBd983INngagv0jI6Ecfs=' } ]; function loadOne(lib, options) { if (lib.ready()) return Promise.resolve(); // One download per library, shared by every caller; reset on // failure so the next call retries just the library that failed. if (lib.pending) return lib.pending; lib.pending = new Promise(function (resolve, reject) { var script = doc.createElement('script'); script.src = lib.src; script.integrity = lib.integrity; script.crossOrigin = 'anonymous'; script.async = true; if (options && options.priority === 'high') script.setAttribute('fetchpriority', 'high'); script.onload = function () { lib.ready() ? resolve() : reject(new Error('Loaded but not available: ' + lib.src)); }; script.onerror = function () { script.remove(); reject(new Error('Could not load ' + lib.src)); }; doc.head.appendChild(script); }); lib.pending.catch(function () { lib.pending = null; }); return lib.pending; } win.loadAlgoliaLibs = function (options) { return Promise.all(LIBS.map(function (lib) { return loadOne(lib, options); })); }; })(window, document); . */ window.hsConversationsSettings = window.hsConversationsSettings || {}; window.hsConversationsSettings.loadImmediately = false; (function (win) { var EVENTS = ['pointerdown', 'keydown', 'touchstart', 'scroll', 'mousemove', 'wheel']; var done = false; /* 19 Oct 2026 - chat widget layout shift (field CLS). Phones fail Core Web Vitals on CLS (p75 ~0.2 site-wide in CrUX for months). Biggest cause found: HubSpot's chat container is fixed to the bottom-right corner and changes size - 100x96 launcher to 282x253 when the welcome message pops up (~5 s after load), and to full screen when a visitor opens the chat. Its top-left corner moves, so Chrome scores it as a layout shift: 0.088 per page view at 360x640 (0.044 at 412x850), on every page. Taps happen inside the chat iframe, so the parent page never sees the input and the open/close shifts count too. Fix: whenever the container's size changes it is made transparent for 400 ms (Chrome doesn't score shifts of invisible elements), then shown again at its new size. Tested on live io1001 at 360x640 in a cookie-less frame: the 0.088 shift no longer appears. The chat itself is unchanged - it just appears 0.4 s later at each resize. Relies on HubSpot's container id; if that changes this does nothing (no error). */ function cloakChatResizes() { var ID = 'hubspot-messages-iframe-container'; function watch(c) { if (c.getAttribute('data-bb-cloak')) return; c.setAttribute('data-bb-cloak', '1'); var last = c.offsetWidth + 'x' + c.offsetHeight, timer = null; new MutationObserver(function () { var size = c.offsetWidth + 'x' + c.offsetHeight; if (size === last) return; last = size; c.style.setProperty('opacity', '0', 'important'); clearTimeout(timer); timer = setTimeout(function () { c.style.removeProperty('opacity'); }, 400); }).observe(c, { attributes: true, attributeFilter: ['style', 'class'], subtree: true, childList: true }); } var found = document.getElementById(ID); if (found) { watch(found); return; } if (!document.body || !('MutationObserver' in win)) return; var mo = new MutationObserver(function () { var c = document.getElementById(ID); if (c) { mo.disconnect(); watch(c); } }); mo.observe(document.body, { childList: true }); setTimeout(function () { mo.disconnect(); }, 30000); } function loadWidget() { var api = win.HubSpotConversations; if (api && api.widget && api.widget.status && api.widget.status().loaded) return; try { cloakChatResizes(); } catch (e) {} if (api && api.widget) api.widget.load(); } function onFirstInteraction() { if (done) return; done = true; EVENTS.forEach(function (type) { win.removeEventListener(type, onFirstInteraction, { passive: true }); }); var start = function () { if (win.HubSpotConversations) loadWidget(); else (win.hsConversationsOnReady = win.hsConversationsOnReady || []).push(loadWidget); }; if ('requestIdleCallback' in win) win.requestIdleCallback(start, { timeout: 1500 }); else setTimeout(start, 200); } EVENTS.forEach(function (type) { win.addEventListener(type, onFirstInteraction, { passive: true }); }); })(window);

91̽»¨

Skip to main content
Characterisation of ioSensory Neurons on the Patchliner
application note

Characterising ioSensory Neurons on the Patchliner, an automated patch clamp system

In this application note developed and published by Nanion, a leading provider of automated patch clamp systems, ioSensory Neurons are characterised for use on the Patchliner.
Characterising ioSensory Neurons on the Patchliner, an automated patch clamp system
In this application note developed and published by Nanion, a leading provider of automated patch clamp systems, ioSensory Neurons are characterised for use on the Patchliner.

In this application note developed and published by Nanion, a leading provider of automated patch clamp systems, ioSensory Neurons are characterised for use on the Patchliner.

Human induced pluripotent stem cells (hiPSCs) are increasingly used in biomedical research for disease modelling and drug discovery. One challenge is the requirement to culture iPSC-derived sensory neurons for long time periods to achieve maturity. This can pose a potential challenge when using techniques such as automated patch clamp which require cells in suspension for the experiments. When cells are cultured for longer (4 weeks or more) this can result in lower success rates for cell capture, and therefore reduced the experiment success rate. 91̽»¨â€™s ioSensory Neurons developed with our opti-ox technology are >99% pure sensory neurons, with a defined nociceptor identity by day 7 post-revival as confirmed by single cell RNA sequencing.

Nanion cultured our ioSensory Neurons for 14-21 days and assessed suitability of these neurons for automated patch clamp use.

In this application note, you will discover:
  • Methods for performing electrophysiology measurements of ioSensory Neurons on the Patchliner.
  • Results showing ioSensory Neurons have excellent success rates for cell capture and sealing following single cell dissociation.
  • Clear indication of ioSensory Neurons displaying TTX sensitive and TTX resistance currents were recorded, indicating functional expression of Nav1.5, Nav1.8 and Nav1.9 ion channels, key targets for pain research.
  • Results highlighting a clear presence of a functional heat activated currents.

This application note was originally

Dr Alison Obergrussberger | Scientific Communications Manager | Nanion Technologies
Dr Nadine Becker | Product Manager | Nanion Technologies
Dr Kefan Yang | Applications Scientist | Nanion Technologies

 

V1

A Obergrussberger et al, 2024.

Nanion

Related pages

91̽»¨ Learn about our range of human iPSC-derived cells for research and drug discovery
Our platform Discover the cell coding platform behind our cells
Contact us Talk to us to learn more about our team and products